Skip to content
This repository has been archived by the owner on Apr 20, 2018. It is now read-only.

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

Open
swftvsn opened this issue Jul 5, 2017 · 2 comments
Open

Comments

@swftvsn
Copy link

swftvsn commented Jul 5, 2017

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
Copy link
Contributor

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
Copy link
Author

swftvsn commented Jul 5, 2017

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants