Router - Clarify params subscription behavior when deactivating a route

[ x ] bug report

Current behavior This is a quote from the official documentation -

The subscriptions are cleaned up when the component is destroyed, protecting against memory leaks, so you don’t need to unsubscribe from the route params Observable.

The subscription is still active.

Expected behavior Angular should unsubscribe from the params observable when the component destroyed. ( or change the documentation )

Minimal reproduction of the problem with instructions You can test this behavior with the delay operator.

@Component({
 ...
})
export class TestComponent implements OnInit {
  params;
  constructor(private route: ActivatedRoute) { }

  ngOnInit() {
    this.params = this.route.params.delay(3000).subscribe(console.log);
  }
}

When navigates to a different route the handler is still running.

You can verify this by calling explicitly to the unsubscribe() method.

ngOnDestroy() {
  this.params.unsubscribe();
}

Now you will see that the handler is not running.

Angular version: 4.0.X

[m0uneer]

I’m searching for a while for the best practices of unsubscribing from observables at Angular and I decided to share with you the result of my searches to review it if I miss something. I see that this issue is related and decided to comment here instead of creating a question issue.

Some of the best practices regarding observables unsubscriptions inside Angular components:

A quote from Routing & Navigation

When subscribing to an observable in a component, you almost always arrange to unsubscribe when the component is destroyed.

There are a few exceptional observables where this is not necessary. The ActivatedRoute observables are among the exceptions.

The ActivatedRoute and its observables are insulated from the Router itself. The Router destroys a routed component when it is no longer needed and the injected ActivatedRoute dies with it.

Feel free to unsubscribe anyway. It is harmless and never a bad practice.

And in responding to the following links:

• (1) Should I unsubscribe from Angular 2 Http Observables?
• (2) Is it necessary to unsubscribe from observables created by Http methods?
• (3) RxJS: Don’t Unsubscribe
• (4) The easiest way to unsubscribe from Observables in Angular
• (5) Documentation for RxJS Unsubscribing
• (6) Unsubscribing in a service is kind of pointless since there is no chance of memory leaks
• (7) Do we need to unsubscribe from observable that completes/errors-out?
• (8) A comment about the http observable

I collected some of the best practices regarding observables unsubscriptions inside Angular components to share with you:

• Never unsubscribe from an http observable as it is finite and it unsubscribes and cleans itself automatically (1), (2) http observable unsubscription is conditional and we should consider the effects of the ‘subscribe callback’ being run after the component is destroyed on a case by case basis. We know that angular unsubscribes and cleans the http observable itself (1), (2). While this is true from the perspective of resources it only tells half the story. Let’s say we’re talking about directly calling http from within a component, and the http response took longer than needed so the user closed the component. The subscribe() handler will still be called even if the component is closed and destroyed. This can have unwanted side effects and in the worse scenarios leave the application state broken. It can also cause exceptions if the code in the callback tries to call something that has just been disposed of. However at the same time occasionally they are desired. Like, let’s say you’re creating an email client and you trigger a sound when the email is done sending - well you’d still want that to occur even if the component is closed (8).
• No need to unsubscribe from observables that complete or error. However, there is no harm in doing so(7).
• Use AsyncPipe as much as possible because it automatically unsubscribes from the observable on component destruction.
• Unsubscribe from the ActivatedRoute observables like route.params if they are subscribed inside a nested (Added inside tpl with the component selector) or dynamic component as they may be subscribed many times as long as the parent/host component exists. No need to unsubscribe from them in other scenarios as mentioned in the quote above from Routing & Navigation docs.
• Unsubscribe from global observables shared between components that are exposed through an Angular service for example as they may be subscribed multiple times as long as the component is initialized.
• No need to unsubscribe from internal observables of an application scoped service since this service never get’s destroyed, unless your entire application get’s destroyed, there is no real reason to unsubscribe from it and there is no chance of memory leaks. (6).
  Note: Regarding scoped services, i.e component providers, they are destroyed when the component is destroyed. In this case, if we subscribe to any observable inside this provider, we should consider unsubscribing from it using the OnDestroy lifecycle hook which will be called when the service is destroyed, according to the docs.
• Use an abstract technique to avoid any code mess that may be resulted from unsubscriptions. You can manage your subscriptions with takeUntil (3) or you can use this npm package mentioned at (4) The easiest way to unsubscribe from Observables in Angular.
• Always unsubscribe from FormGroup observables like form.valueChanges and form.statusChanges
• Always unsubscribe from observables of Renderer2 service like renderer2.listen
• Unsubscribe from every observable else as a memory-leak guard step until Angular Docs explicitly tells us which observables are unnecessary to be unsubscribed (Check issue: (5) Documentation for RxJS Unsubscribing (Open)).
• Bonus: Always use the Angular ways to bind events like HostListener as angular cares well about removing the event listeners if needed and prevents any potential memory leak due to event bindings.

A nice final tip: If you don’t know if an observable is being automatically unsubscribed/completed or not, add a complete callback to subscribe(...) and check if it gets called when the component is destroyed.

[ribizli]

The ActivatedRoute and its observables are insulated from the Router itself. The Router destroys a routed component when it is no longer needed and the injected ActivatedRoute dies with it.

My understanding of this is that the source params/data/etc observables are garbage collected when the component and its injector with the ActivatedRoute gets garbage collected. No wording about unsubscribe or any cleanup. It seems, that a delayed Observable still holds an active reference for a timeout callback or subscriber (??? I’m not aware about the internals) preventing it from garbage collection. After the timeout fires (or in real scenarios the HTTP returns), the Observable dies. Anyway I don’t see this as a memory leak, rather just a specific case what should be handled manually. But true, this should be well documented, since some HTTP call should be also cancelled to prevent from some side effects and save some resources.

Can someone confirm my assumptions?