Reactive-Extensions / RxJS

The Reactive Extensions for JavaScript
http://reactivex.io
Other
19.49k stars 2.1k forks source link

Let there be mechanism to make it clear if subscriber should unsubscribe #1496

Open swftvsn opened 7 years ago

swftvsn commented 7 years ago

This is more of a broad feature request that spans all RxFamily. I didn't know where to put this, so here it goes.

I've developed Angular apps, and one thing that is confusing and often overlooked is the unsubscription of previously subscribed streams.

You can see the discussion here: https://stackoverflow.com/questions/38008334/angular-rxjs-when-should-i-unsubscribe-from-subscription

I've also run in to this in Java applications, and I suspect that this spans all RxFamily. All the "fixes" to this problem are conventions, as there is no signal nor distinction when subscribing if

a) this is finite or infinite subscription b) if someone else manages the unsubscription

There should be a mechanism to signal this to subscribers (and tooling) to make it clear. Like in http.get calls we all know it's finite, one-next-or-error type of thing (a promise basically), so there should be a way to convey this information to subscriber.

The only proposal I can come up with is to introduce ManagedObservable (AutoTerminatedObservable?) type, that could be used to signal to the subscriber that the subscription is expected to be terminated by the party from which the observable was acquired from and as such does not pollute or accumulate if not unsubscribed by the caller.

Simple and concise: if you subscribe to ManagedObservable, don't bother worrying about unsubscription.

This would let also tooling to warn users about missing unsubscriptions when the context in which the subscription has been established contained enough information. (Not nearly all cases, but I could see this happening in Angular / Typescript components for an example.)

What do you think?

paulpdaniels commented 7 years ago

Have you seen this https://medium.com/@benlesh/rxjs-dont-unsubscribe-6753ed4fda87 ?

General thinking is that you should avoid explicit unsubscribe, the whole point of the stream is that it should complete when it is done, you shouldn't need to actually call unsubscribe.

swftvsn commented 7 years ago

Thanks for the link! It was a good read and simplifies the problem. Maybe this is part of my learning path trying to wrap my head around RxXX, but it just feels that I'd like to have the good old promise back when a framework uses Observable to imitate one.

The link, in my mind, is only how one can get rid of some of the boilerplate coding, but in the end the examples still unsubscribe (or take(x) or takeUntil ...)

That said, I'm waiting to get deep enough to not miss Promises anymore :D