So many years with Angular.
So many years with RxJS.
Yet people still fight over "when NOT to unsubscribe".
Truth is. It's not even worth the conversation.
Just unsubscribe always. Simple.
I have recently posted the same advice on my social media(X/LinkedIn).
While majority agreed without a doubt. About 10% decided that it's a perfect opportunity to showcase deep and expert knowledge of how there is NO NEED to always unsubscribe.
The prime and crown example:
- HttpClient cold observable
I have been told that:
- It's a terrible advice
- It's a big overhead to always unsubscribe
- People should never follow this advice
- It's absolutely wrong
- It's redundant code
- It's a bold assumption
- Go ask Angular Team and so on...
Yes technically HttpClient completes automatically in like 99% of cases.
However this doesn't mean that you have to deliberately find and safe guard places where you subscribe to HttpClient Observable to avoid unsubscribing.
Simple "Why":
- It doesn't make any sense
- There is 0 overhead to unsubscribe since you have to do it in other places as well ( should be in your blood already cmon!"
- Value consistency over "being smart about things"
- Never think about when not to unsubscribe and focus on important things.
- Value consistency...
- Value consistency...
Not convinced? Advanced "Why":
- Citing a friend, because i could have not put it together in a batter way:
- Additionally this conversation has been "silently" resolved in one of the GitHub issues from 2022. Feedback from "Engineering" means response from devs.
source: https://github.com/angular/angular/issues/46542
- And finally in new Angular docs website. It's clearly stated that:
Once the response returns, Observables from HttpClient usually complete (although interceptors can influence this).
Because of the automatic completion, there is usually no risk of memory leaks if HttpClient subscriptions are not cleaned up. However, as with any async operation, we strongly recommend that you clean up subscriptions when the component using them is destroyed, as the subscription callback may otherwise run and encounter errors when it attempts to interact with the destroyed component.
source: https://angular.dev/guide/http/making-requests#http-observables
Now you can use this resource if your teammates keep nitpicking that you are unsubscribing from HttpClient Observables. Or any other they think it's "safe" not to do it.
Tip: Avoid subscribing in first place, do everything to end up with async pipe.
PS: as of Angular v16 - the best way to unsubscribe is by using takeUntilDestroyed()
Like my stuff? Follow me on LinkedIn or X
Big things happening at angularspace.com ( Early Access )
Top comments (7)
Thanks for that article. I always wondered why some people try to make their life harder by making a few single exceptions where it MIGHT not be necessary to unsubscribe instead of going autopilot and just do it everywhere. One more reason to always unsubscribe which is rather implicit in the cited post:
The underlying technology for the async call might change at any time and all of a sudden you actually have to unsubscribe (e.g. the value might come from an Ngrx store instead of http).
I disagree about Bob advice related to component destruction for non GET requests with HttpClient because that's prioritizing technical aspects over UX.
If I navigate away from a 'deletion' page after hitting the related button, the request might not even been sent to the server (due to poor network quality) or might be about to reply with an error the user will never get.
There are some solutions to prevent it or to keep the user notified but for most cases, I would avoid to unsubscribe on component destruction for such use cases.
In general your component should be completely unaware of observables that they are subscribing to are HTTP - should be abstracted away. The right balance of technical aspects/code complexity is up to you ofc. But it's a fact that any kind of subscription should be cleaned up :) . PS: It's not a Bob advice - Bob was a technical writer for Google - it's a response from Engineering means developers.
I agree about cleaning up but promoting it with component destruction is tidying some technical details way too much. With an optimistic update feature, I'd rather use the timeout rxjs operator to clean up if it's taking too much time rather than implicitly implying to the user that the instant visual feedback they got meant nothing because they navigate away from the current page.
If I navigate off a page without any feedback to my action, I personally would actually expect it to be cancelled. Otherwise you would have to get some kind of popup saying: "hey, that user you deleted on of the previous pages 2 minutes ago just got deleted". There are mechanisms to achieve this behavior if you really need to, but making an http call in a component and just let it dangle no matter what is not one of them imo.
With optimistic updates, you already get an instant visual feedback, the real update is a technical details which should not be affected by a user navigation.
How to create problems that didn't existed before, and keep discussing endlessly about them? Use a crappy corporate lib as Angular, React or TypeScript. You get the exact same problems you had before, plus the ones created while trying to reinvent the wheel, plus the ones pushed by the hype zombie community, that have no ability to distinguish anything without a propaganda budget.