If you are sure the observable completes within the lifetime of the app/component, you can get away not unsubscribing. And this you need to be sure if you care about memory leakages, so what are your thoughts about both sources you mention?
Alternatively and maybe even better is to use async pipe in the template. So you don’t need to worry about it. This assuming that an observable not leading to UI effects is basically something you don’t want anyway.
In my opinion we don’t need to unsubscribe from HttpClient and ActivatedRoute observables as they should be unsubscribed automatically by Angular. But on the other hand I heard people telling that You should unsubscribe from everything that you subscribed to.
In my code I always unsubscribe from Subjects or similar emmiters… e.g. subscription on PullToRefresh event has to be unsubscribed on component destroy because if we initialize component again we will have two subscriptions now which will lead to calling PullToRefresh twice what is intolerably.
Assuming this isn’t rhetorical hyperbole, I think there are substantial differences here.
any subverts the type system, making code much harder to read, and pushing errors that should be caught at build time down to runtime. providing proper types for things is virtually always an improvement with no downside;
function (virtually always accidentally) shifts execution context, making this inaccessible. again, arrow functions are an improvement with no negative side effects;
anything that can be done by getElementById can be replaced by property bindings or @ViewChild at the outside.
Now, consider these scenarios:
A. You have a client-server app that uses tokens for authentication that expire. You would like to notice when any HTTP request sent from the app fails due to an expired token and redirect the user to a place where they can reenter authentication credentials.
B. You have a service that exposes a Bishop BerkeleyObservable that is attached to a button. When nobody is listening to the Observable, the button appears disabled. When somebody is listening, a click on the button causes the Observable to emit. I frequently use this idiom for contextually enabled toolbars.
C. You have a form with 12 inputs all fed values by an upstream Observable. The current value of this Observable also influences whether or not a confirmation dialog is presented in response to a button click.
I can’t think of any better way to write any of those without directly using subscribe, and I don’t think the presence of that subscribe introduces any ill effects. I can’t see how one would write A without subscribe; I’ve tried doing B with just the AsyncPipe and found it unwieldy. Likewise C could probably be done, but with multiple subscriptions that I don’t see the corresponding added value to justify.
I would argue that ngneat/until-destroy implements that author’s recommended “best practice” in a much cleaner way, as it does not abuse inheritance.