Discussion: Subscribe returns a cancellation function

[zenparsing]

In the current version, subscribe returns a cancellation function. Previously, subscribe returned a "subscription" object with an "unsubscribe" method.

Rationale:

1. Since working on this project, I've typed in "subscription.unsubscribe" many, many times. It's ugly and a real pain.
2. We currently haven't identified any essential capabilities that need to be returned from "subscribe" other than the cancellation function. It's nice to avoid useless wrapper objects.
3. Any additional capabilities returned from "subscribe" are probably going to be POLA-problematic.
4. The return types of "subscribe" and the subscriber function align nicely.

Regarding 4:

We frequently want to "chain" observables like this:

function x(observable) {
    return new Observable(observer => observable.subscribe({
        // ... whatever
    });
}

If "subscribe" returns something other than a () => void function, then we have to bake-in some messy overloading in order to make that chaining nice and pleasant. RxJS makes use of overloading in several places (also "subscribe") which I would like to avoid.

Thoughts?

[zenparsing]

@RangerMauve Bacon actually just returns a cancellation function.

https://baconjs.github.io/api.html#observable-subscribe

Also, it's very unlikely that "dispose" will work. "Dispose" is an architectural feature of .NET, and JS doesn't have such a feature.

[zenparsing]

I've created two different branches, exploring both of the following options:

1. Rename this proposal's "subscribe" to "observe", letting implementations choose whatever semantics they want for "subscribe". (branch observe-method)
2. Return an object with an "unsubscribe" function. (branch subscription-object)

I prefer option 1, given that different Observable implementations in the wild don't agree on the return type of "subscribe" anyway, and since Rx wants extended semantics for "subscribe" beyond what TC39 will want.

[RangerMauve]

@zenparsing Yeah, I was mostly referencing the specific name they gave the function.

Didn't know that that's where dispose was taken from. :o

[benjamingr]

I prefer both :D (observe and returning an object), but again - I don't want to block the proposal's progression.

[benlesh]

bacon and rx refer to it as dispose

RxJS 5 uses unsubscribe, this is mostly because it was trying to align itself with this spec, which has changed since.

[RangerMauve]

Perfect! I like the sound of unsubscribe more, anyway. :D

[jhusain]

Originally the move away from observe was motivated by avoiding a clash with Object.observe. Given that O.o's progress has stalled it's worth considering the name again. Personally I believe the subscribe/unsubscribe option is the most ergonomic proposal, but I also acknowledge the issue is one of taste. Closures and objects both have state.

JH

On Oct 28, 2015, at 8:20 AM, Benjamin Gruenbaum notifications@github.com wrote:

I prefer both :D (observe and returning an object), but again - I don't want to block the proposal's progression.

— Reply to this email directly or view it on GitHub.

[benjamingr]

Wait, who is actually pursuing returning a function and not an object at this point?

[RangerMauve]

@benjamingr I know @zenparsing is in favor of a function. I kinda like the idea too, however I like the idea of having an explicit unsubscribe, too. @jhusain Seemed to be in favor of the function at first but now I guess he's OK with the object, too.

[Frikki]

@blesh Would RxJS 5 change its API if this spec changes?

[benlesh]

@Frikki ... RxJS 5 would have to change it's API if this spec resulted in a subscribe method that returned a cancellation function, which I believe is the current spec. However, if it goes back to returning an object with an unsubscribe method on it, then RxJS 5 will not have to change.

Ultimately, if RxJS 5 does not align with the spec, a future version (RxJS 6?) will. It was one of the goals of the rewrite of RxJS, albeit a less important goal than the others.

[zenparsing]

@benjamingr I am still in favor of returning a cancellation function, because it makes the whole design just a bit cleaner and simpler. Clean and simple is a big thing with me : )

[benlesh]

@zenparsing clean an simple to implement !== clean and simple to use/work with. I think we can assume the implementation part will be handled for the consumers of the language.

[zenparsing]

As of be763e33413c4888e269024ac63945643ef36d8a, subscribe returns a subscription object.

[zenparsing]

@blesh Since this spec is now returning a subscription object from subscribe, any reason to leave this issue open?

[benlesh]

Nope. Unless you're waiting for me to hug you. Because I will.

[zenparsing]

Feel da love