No Unsubscribing from Signals about interstellar HOT 11 CLOSED

I think it's pretty acceptable to make next and subscribe final methods that return a token to unsubscribe rather than keep chaining.

Chaining with both of these methods is a bit weird I think because to a viewer it would look as if the value stream was being modified but in reality it was just being 'tapped'.

Both RxSwift and ReactiveCocoa solve this via a separate API on vs subscribe*

from interstellar.

This is actually on purpose. Signals should be as immutable as possible. To get rid of a Signal just remove the reference to it, then it will deallocate and take all closures with it.

from interstellar.

During the last days I was thinking about implementing something similar to reactive cocoa that gives back a subscription-object that can be used to explicitly unsubscribe from a signal. But that would also mean that subscribe is not chainable anymore. Would you think that tradeoff is ok?

from interstellar.

Why not use an inout parameter to return the subscription object? That would preserve chaining. Also, could maintain previous subscribe method that doesn't return a subscription object to maintain source compatibility.

from interstellar.

A use case: If I create a signal from NSNotificationCenter, I'd really want to unsubscribe it, where I can remove the observer from notification center.

from interstellar.

This will be addressed in Interstellar 2, but currently you can achieve it with a workaround:

Create a custom object that subscribes itself to NSNotificationCenter. The only purpose of this object is to update a Signal<NSNotification> and keep a strong reference to it. Once you don't want to receive updates anymore, you can just let go of the signal (e.g setting it to nil on the object), so it will deallocate and release all subscriptions.

class NotificationObserver: NSObject {
    var signal: Signal<NSNotification>? = Signal<NSNotification>() {
        didSet {
            if signal == nil {
                NSNotificationCenter.defaultCenter().removeObserver(self)
            }
        }
    }

    override init() {
        super.init()
        NSNotificationCenter.defaultCenter().addObserver(self, selector: "update", name: NSUserDefaultsDidChangeNotification, object: nil)
    }

    func update(notification: NSNotification) {
        signal?.update(notification)
    }
}

let observer = NotificationObserver()
let signal = observer.signal //here is your signal
observer.signal = nil //unsubscribing

from interstellar.

@JensRavens thanks!

from interstellar.

@JensRavens I'm moving our project over to v2 as an experiment, and I just wanted to thank you for updating the readme along with the code 🙇 It's making things a lot easier.

from interstellar.

It seems that mapping a Observable (or signal) will also add a subscription to the dictionary of the initial Observable. Since this does not return a ObservableToken there is no way to remove the subscription after it has been added from the map

from interstellar.

@NeonOrion Yep, this is intentional. map is just convenience over subscribe. If you want all the options, use subscribe instead.

from interstellar.

V2 has been released now, including the unsubscription api.

from interstellar.