New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RAC 3.0: Observing MutableProperty without side-effects #2061

Closed
patr1ck opened this Issue Jun 2, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@patr1ck

patr1ck commented Jun 2, 2015

It seems reasonable to want to observe a MutableProperty value as a hot signal instead of having to call start() on it's producer, so that you can avoid triggering side-effects. I can simulate this (I think) by doing something like this:

        userImage.producer
            |> skip(1)
            |> start(next: {
                if let image = $0 { saveImageInCache(image, accountID: self.userAccountID) }
        })

But this feels kind of wrong – is there a better way to do this? Maybe I missed an easy way to convert a SignalProducer to a Signal? I noticed MutableProperty does have an observer: Signal property, but it's private, and I imagine with good reason.

I'm new to RAC, so I apologize in advance if this should be obvious, or is a crazy idea for other reasons.

@neilpa neilpa added the question label Jun 2, 2015

@neilpa

This comment has been minimized.

Member

neilpa commented Jun 2, 2015

If you need to drive the cache from changes on the property, then this seems like a reasonable approach. The side-effect of the producer on a MutableProperty is just the subscription itself. It's more-or-less a hot signal but modeled as a producer so the current value can be sent immediately on subscription.

@neilpa

This comment has been minimized.

Member

neilpa commented Jun 2, 2015

I noticed MutableProperty does have an observer: Signal property, but it's private, and I imagine with good reason.

IMO, that's a bit misnamed. That's the sink which maintains all the active subscriptions, forwarding to the real observers when an event is sent.

@patr1ck

This comment has been minimized.

patr1ck commented Jun 2, 2015

Cool, thank you!

I may refactor my code to not load the cache when setting the property (and do it somewhere else) since on second thought it seems that structure might not be sound. Good to know I'm not abusing the framework too badly though. Thanks again!

@patr1ck patr1ck closed this Jun 2, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment