You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 20, 2018. It is now read-only.
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?
The text was updated successfully, but these errors were encountered:
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.
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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?
The text was updated successfully, but these errors were encountered: