The Wayback Machine - https://web.archive.org/web/20240413062440/https://github.com/angular/angular/issues/46542
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: clearly explain if/when we need to unsubscribe from HttpClient calls #46542

Closed
digeomel opened this issue Jun 28, 2022 · 8 comments
Closed
Assignees
Labels
area: common/http help wanted An issue that is suitable for a community contributor (based on its complexity/scope). P2 The issue is important to a large percentage of users, with a workaround
Milestone

Comments

@digeomel
Copy link

digeomel commented Jun 28, 2022

Description

Hello, I've been going through the documentation of the HttpClient service (https://angular.io/guide/http) trying to find any mention of whether it is necessary to unsubscribe from the generated observables or not, and the only mention I could find was about using the AsyncPipe, which is irrelevant (because we don't have to or might not want to use it).

So, I think the documentation should clarify when (if ever) we need to unsubscribe from calls.

Update:
Perhaps I should clarify a bit more. This article:
https://medium.com/angular-in-depth/why-you-have-to-unsubscribe-from-observable-92502d5639d0
explains very well the reasons why we should unsubscribe from all HttpClient observables always.
Personally, I've struggled to convince my team to do it, because their usual answer is that HttpClient will do it automatically and of course very few people bother to read beyond the official documentation which doesn't mention anything about unsubscribing.
I have been doing it for a long time with Net Basal's excellent ng-neat/until-destroy library, but I feel that this is such a core concept of any real-life Angular app that it should be clearly documented.

@ngbot ngbot bot modified the milestone: needsTriage Jun 28, 2022
@dylhunn dylhunn added the help wanted An issue that is suitable for a community contributor (based on its complexity/scope). label Jun 28, 2022
@josmar-crwdstffng josmar-crwdstffng added the P2 The issue is important to a large percentage of users, with a workaround label Jun 28, 2022
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Jun 28, 2022
@bob-watson
Copy link
Contributor

Feedback received from engineering:

Short answer: always unsubscribe.
Slightly longer answer: It's easier to just always unsubscribe than try to learn exactly when you need to.
👍 and when you need to can be super subtle and dependent on interceptors, etc.
Best practice is to always unsubscribe when a component is destroyed.

@digeomel
Copy link
Author

digeomel commented Aug 4, 2022

@bob-watson that's great and as I wrote above this is exactly what I recommend my team to do, but can we please have it written in the documentation, instead of just having the generic mention of the async pipe?

@digeomel
Copy link
Author

digeomel commented Aug 4, 2022

Related to this topic, another pain point that I struggled to convince my team about is to never subscribe to such observables in (singleton) services, at least not without an extra mechanism to unsubscribe from the previous observable before creating a new one. I suppose this should be obvious coming from the recommendation to always unsubscribe when a component is destroyed, but again, would be nice to clarify in the documentation.

@ileil ileil self-assigned this Aug 8, 2022
@ileil
Copy link
Contributor

ileil commented Aug 10, 2022

Under "Starting the request", added the following note:

You should always unsubscribe from an observable when a component is destroyed. You can use the AsyncPipe to subscribe to and unsubscribe from an observable automatically.

@Tomassito
Copy link

Tomassito commented Aug 12, 2022

@pkozlowski-opensource sorry, I don't think I understand how this is solving the issue here. It's been stated that the documentation of HttpClient is not clear regarding the need to unsubscribe.
Here we have https://stackoverflow.com/a/35043309/6456946 a lot of discussion regarding the topic and it shows how different opinions devs have. Now it would be fair if angular provided their recommendation as to if and why.
@digeomel do you agree?

@digeomel
Copy link
Author

@Tomassito @pkozlowski-opensource @ileil I would word it slightly different, explaining why always unsubscribing is important:

You should always unsubscribe from observables, even those created by the HttpService, because of edge cases (e.g. slow network) where the built-in unsubscribe mechanism may not kick in when the component is destroyed. When the observable is used in a component, you can use the AsyncPipe in the component template to achieve this.

But the line added by @ileil and the clarifications provided here are already an improvement 😄 👍🏼 Maybe we can link to this discussion from the docs?

@Tomassito
Copy link

Yes, there should be definitely more information on what to expect from the observables exposed by angular services, especially the httpClient. Do docs even mention the fact that an http request auto completes?

@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: common/http help wanted An issue that is suitable for a community contributor (based on its complexity/scope). P2 The issue is important to a large percentage of users, with a workaround
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants