Unsubscribing from Observables inside services?

Question

When looking at code examples, I often see the case where observables inside services are not unsubscribed from.

Here is an example:

export class AuthGuard implements CanActivate {

    private isLoggedIn: boolean;
    private isLoggedIn$: Observable<boolean>;


    constructor(private authService: AuthService, private router: Router) {
        this.isLoggedIn$ = this.authService.isLoggedIn();

        this.isLoggedIn$.subscribe(res => {
            if (res) {
                this.isLoggedIn = true;
            } 
            else {
                this.isLoggedIn = false;
            }
        });
    }

    canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {
        if (this.isLoggedIn) {
            return true;
        }
        else {
            this.router.navigate(['login']);
            return false;
        }     
    }
}

Is there a reason why you would not unsubscribe from the observable this.isLoggedIn$ in this case? Or is the above example just bad coding leading to memory leaks?

Possible duplicate of [Is it necessary to unsubscribe from observables created by Http methods?](https://stackoverflow.com/questions/35042929/is-it-necessary-to-unsubscribe-from-observables-created-by-http-methods) — Vlad274, Aug 10 '18 at 17:09
https://brianflove.com/2016/12/11/anguar-2-unsubscribe-observables/ please visit this article anyhow the above its just bad coding example — Vaibhav, Aug 10 '18 at 17:11
I had read the article before asking the question .... the article does not relate anything regarding the question of whether one should unsubscribe from observables even if the observable is not contained in a Component but in a Service — Michael, Aug 10 '18 at 17:34
@Vlad274: I now that you don't have to unsubscribe from observables created by http methods ... but what about observables created by Services? — Michael, Aug 10 '18 at 17:35

Poul Kruijt · Answer 1 · 2018-08-10T18:05:40.250

For core services an unsubscribe is not really necessary, because the service lives as long as the application lives, and the service is a singleton. Problem is that you have to make sure you always use it as a singleton (for better solutions, read below)

For component services an unsubscribe should be placed inside the ngOnDestroy of the service, because services actually can implement this NgOnDestroy hook. A better way would be to use the takeUntil(this.destroy) pipe and emit this on destroy.

An even better way would be to use async pipe inside the template, and never really directly subscribe to things like these.

In your guard on the other hand, you can use the take(1) pipe, this will take the first emit and immediately unsubscribes without the need for you to do it, this will change your example to this. As you can see, no subscribe inside the code:

export class AuthGuard implements CanActivate {

  constructor(private authService: AuthService, private router: Router) {}

  canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {
    return this.authService.isLoggedIn().pipe(
      take(1),
      tap((loggedIn) => {
        if (!loggedIn) {
          this.router.navigate(['login'])
        }
      })
    );    
  }
}

Bottom line, try to keep your application a stream of Observables using the async inside templates and the rxjs pipe function, instead of subscribing and storing sub results. To make the isLoggedIn() emit the last result when subscribed to, you can use a shareReplay() pipe or make it a BehaviourSubject to begin with.

Personally I think not unsubscribing because "it lives forever" is a bad practice. Things may change and this is an implementation detail. If you ever scope the lifetime, will you really remember to go through and fix it all? — Ingo Bürk, Aug 10 '18 at 20:38
@IngoBürk That's exactly what I said in the first paragraph :) and went into more detail about this in the rest of the answer — Poul Kruijt, Aug 10 '18 at 20:45

score 0 · Accepted Answer · answered Aug 10 '18 at 18:03

When looking at code examples, I often see the case where observables inside services are not unsubscribed from.

You are looking at a bug.

Is there a reason why you would not unsubscribe from the observable this.isLoggedIn$ in this case?

If you wanted to leak memory.

Or is the above example just bad coding leading to memory leaks?

Yes, it's leaking memory. The subscribe function will continue to be executed after the object referenced by this is destroyed. It might never happen if this object is never destroy, but it's an example of code that would fail a unit test where objects are created temporarily.

Objects tagged with @Injectable() often behave like singletons or have weak references. It might be working for a while, but once you use it in a temporary case it'll leak memory.

Unsubscribing from Observables inside services?

2 Answers2