In my angular project, I have multiple subscriptions in a few components. So I use properties inside of it to store subscriptions, and in destroy function, I unsubscribe all of them. The problem is that the code becomes larger unnecessary larger. My question is, is there any way to unsubscribe all subscriptions at ones?
-
2Does this answer your question? [Angular/RxJs When should I unsubscribe from \`Subscription\`](https://stackoverflow.com/questions/38008334/angular-rxjs-when-should-i-unsubscribe-from-subscription) – R. Richards Jun 22 '20 at 19:55
-
1Consult this thread: https://stackoverflow.com/questions/38008334/angular-rxjs-when-should-i-unsubscribe-from-subscription/41177163 – mbojko Jun 22 '20 at 19:56
3 Answers
I tend to store all my subscriptions in an array..
private subs: Subscription[] = []
ngOnInit() {
this.subs.push(
this.obs1.subscribe(),
this.obs2.subscribe() // etc
)
}
ngOnDestroy() {
this.subs.forEach(s => s.unsubscribe())
}
other people prefer other methods. just be creative.

- 28,215
- 4
- 48
- 65
There is many ways to do that but we can't avoid the boilerplate, you can use the ways above or use a decorator for that but keep in mind that there are exceptions where you don't have to unsubscribe:
No Need of unsubscribe in these cases
In case of HttpClient calls because the observable emit one value (success or error) and complete automatically.
In case or ActivatedRoute subscription because the Router will destroy it when the component is destroyed automatically
use of Async pipe

- 20,445
- 5
- 43
- 52
A recommanded way to unsubscribe to an observable is to call
ngOnDestroy () {
this.obs.next();
this.obs.complete();
}
To do it for all observable at once, you can declare a subject and use takeUntil
from rxjs :
ngUnsubscribe = new Subject();
... code...
ngOnInit() {
this.myObs.pipe(takeUntil(this.ngUnsubscribe))
.subscribe(_ => ...);
}
ngOnDestroy() {
this.ngUnsubscribe.next();
this.ngUnsubscribe.complete();
}
I do it this way because I noticed that in my project, calling .unsubscribe()
wasn't working as expected. Switching from component A to B and then back to A created a second (then third, etc.) subscription and finally fixed by applying advice from this thread).

- 4,794
- 1
- 10
- 15
-
careful with the word `proper` ... this is one method that some people like. it's not endorsed by the angular team or the rxjs team or anyone of note. it has subtle drawbacks to it... your note is entirely incorrect. – bryan60 Jun 22 '20 at 19:39
-
-
@bryan60 Proved at work many times, feel free to leave memory leak in your project – Quentin Grisel Jun 22 '20 at 19:46
-
1Make a demo of it happening, it's objectively false. Worked on dozens of enterprise angular applications. unsubscribing has never once caused a leak. the `takeUntil` method has though when people mess it up and put it in the wrong place. – bryan60 Jun 22 '20 at 19:48
-
@bryan60 I finally found the thread i was talking about (edited the answer). We had leak using ngrx. A subscription was kept alive even after calling `.unsubscribe()`, we could see it clearly in the redux console and network tab since it was related to an API call. I don't think it was a 'bad use' of ngrx since just switching to the solution I propose fixed it. – Quentin Grisel Jun 22 '20 at 19:55
-
the thread you've linked doesn't say anything about unsubscribe not disposing of the subscription in any cases. The claim you're making is 100% objectively untrue. and angular's own async pipe uses unsubscribe: https://github.com/angular/angular/blob/master/packages/common/src/pipes/async_pipe.ts – bryan60 Jun 22 '20 at 20:03
-
@bryan60 Right, but it fixed my issues and also seems to be (one of) the recommanded solution, either from Angular or rxjs. Now, you're right saying it sould not be a 'claim', i'll change it to make it more 'opinion/advice' oriented. – Quentin Grisel Jun 22 '20 at 20:09