Is it necessary to unsubscribe from observables created by Http methods?

Question

Do you need to unsubscribe from Angular 2 http calls to prevent memory leak?

 fetchFilm(index) {
        var sub = this._http.get(`http://example.com`)
              


        

Answer 1

You shouldn't unsubscribe from observables that completes automatically (e.g Http, calls). But it's necessary to unsubscribe from infinite observables like Observable.timer().

Answer 2

RxJS observable are basically associated and work accordingly you subscribe it. When we create the observable and the movement we complete it, observable automatically gets closed and unsubscribed.

They work in the same fashion of the watchers but quite different order. The better practice to unsubscribe them when component is getting destroy.We could subsequently do that by eg. this.$manageSubscription.unsubscibe()

If we have created the observable like below mentioned syntax such as

** return new Observable((observer) => { ** // It makes observable in cold state ** observer.complete() **}) **

Answer 3

What are you people talking about!!!

OK so there's two reasons to unsubscribe from any observable. Nobody seems to be talking much about the very important second reason!

1) Clean up resources. As others have said this is a negligible problem for HTTP observables. It'll just clean itself up.

2) Prevent the subscribe handler from being run.

(For HTTP this actually will also cancel the request in the browser - so it won't waste time reading the response. But that's actually an aside to my main point below.)

The relevance of number 2 is going to depend upon what your subscribe handler does:

If your subscribe() handler function has any kind of side effect that is undesired if whatever calls it is closed or disposed then you must unsubscribe (or add conditional logic) to prevent it from being executed.

Consider a few cases:

1) A login form. You enter username and password and click 'Login'. What if the server is slow and you decide to hit Escape to close the dialog? You'll probably assume you weren't logged in, but if the http request returned after you hit escape then then you will still execute whatever logic you have there. This may result in a redirect to an account page, an unwanted login cookie or token variable being set. This is probably not what your user expected.

2) A 'send email' form.

If the subscribe handler for 'sendEmail' does something like trigger a 'Your email is sent' animation, transfer you to a different page or tries to access anything that has been disposed you may get exceptions or unwanted behavior.

Also be careful not to assume unsubscribe() means 'cancel'. Once the HTTP message is in-flight unsubscribe() will NOT cancel the HTTP request if it's already reached your server. It will only cancel the response coming back to you. And the email will probably get sent.

If you create the subscription to send the email directly inside a UI component then you probably would want to unsubscribe on dispose, but if the email is being sent by a non-UI centralized service then you probably wouldn't need to.

3) An Angular component that is destroyed / closed. Any http observables still running at the time will complete and run their logic unless you unsubscribe in onDestroy(). Whether the consequences are trivial or not will depend upon what you do in the subscribe handler. If you try to update something that doesn't exist anymore you may get an error.

Sometimes you may have some actions you would want if the component is disposed, and some you wouldn't. For example maybe you have a 'swoosh' sound for a sent email. You'd probably want this to play even if the component was closed, but if you try to run an animation on the component it would fail. In that case some extra conditional logic inside subscribe would be the solution - and you would NOT want to unsubscribe the http observable.

So in answer to the actual question, no you don't need to do it to avoid memory leaks. But you need to do it (often) to avoid unwanted side effects being triggered by running code that may throw exceptions or corrupt your application state.

Tip: The Subscription contains a closed boolean property that may be useful in advanced cases. For HTTP this will be set when it completes. In Angular it might be useful in some situations to set a _isDestroyed property in ngDestroy which can be checked by your subscribe handler.

Tip 2: If handling multiple subscriptions you can create an ad-hoc new Subscription() object and add(...) any other subscriptions to it - so when you unsubscribe from the main one it will unsubscribe all the added subscriptions too.

Answer 4

After a while of testing, reading documentation and the sourcecode of the HttpClient.

HttpClient: https://github.com/angular/angular/blob/master/packages/common/http/src/client.ts

HttpXhrBackend : https://github.com/angular/angular/blob/master/packages/common/http/src/xhr.ts

HttpClientModule: https://indepth.dev/exploring-the-httpclientmodule-in-angular/

Angular Univeristy: https://blog.angular-university.io/angular-http/

This particular type of Observables are single-value streams: If the HTTP request is successful, these observables will emit only one value and then complete

And the answer to the whole Issue of "do i NEED" to unsubscribe ?

It depends. Http call Memoryleaks are not a issue. The issues are the logic in your callback functions.

For example: Routing or Login.

If your call is a login call, you don't have to "unsubscribe" but you need to make sure if the User leaves the page, you handle the response properly in the absence of the user.

this.authorisationService
      .authorize(data.username, data.password)
      .subscribe((res: HttpResponse<object>) => {
          this.handleLoginResponse(res);
        },
        (error: HttpErrorResponse) => {
          this.messageService.error('Authentication failed');
        },
        () => {
          this.messageService.info('Login has completed');
        })

From annoying to dangerous

Now just imagine, the network is slower than usual, the call takes longer 5 seconds, and the user leaves the login view and goes to a "support view" .

The component may not be active but the subscription. In case of a response, the user will be suddenly rerouted (depending on your handleResponse() implementation).

This is not good.

Also just imagine the user leaves the pc, believing he is not logged in yet. But you logic logs the user in, now you have a security issue.

What can you do WITHOUT unsubscribing?

Make you call dependent on the current state of the view:

  public isActive = false;
  public ngOnInit(): void {
    this.isActive = true;
  }

  public ngOnDestroy(): void {
    this.isActive = false;
  }

User .pipe(takeWhile(value => this.isActive)) to make sure the response is only handled when the view is active.

this.authorisationService
      .authorize(data.username, data.password).pipe(takeWhile(value => this.isActive))
      .subscribe((res: HttpResponse<object>) => {
          this.handleLoginResponse(res);
        },
        (error: HttpErrorResponse) => {
          this.messageService.error('Authentication failed');
        },
        () => {
          this.messageService.info('Login has completed');
        })

But how can you be sure that the subscription isn't causing memoryleaks ?

You can log if the "teardownLogic" is applied.

The teardownLogic of a subscription will be called when the subcription is empty or unsubscribed.

this.authorisationService
      .authorize(data.username, data.password).pipe(takeWhile(value => this.isActive))
      .subscribe((res: HttpResponse<object>) => {
          this.handleLoginResponse(res);
        },
        (error: HttpErrorResponse) => {
          this.messageService.error('Authentication failed');
        },
        () => {
          this.messageService.info('Login has completed');
    }).add(() => {
        // this is the teardown function
        // will be called in the end
      this.messageService.info('Teardown');
    });

You don't have to unsubscribe. You should know if there are issues in your logic, that could cause Problems in your subscription. And take care of them. In the most cases, it won't be a issue, but especcialy at critical tasks like autorization, you should take care of unexpected behaviour, wether its with "unsubscribe" or a other logic like piping or conditional callback functions.

why not just always unsubscribe?

Imagine you make a put or post request. The server recieves the message either way, just the response takes a while. Unsubscribing, won't undo the post or put. But when you unsubscribe, you won't have the chance to handle the response or inform the User, for example via Dialog or a Toast/Message etc.

Wich causes the User to believe, that the put/post request was not done.

So it depends. It is your design decision, how to deal with such issues.

Answer 5

Also with the new HttpClient module, remains the same behaviour

Answer 6

Unsubscribing is a MUST if you want a deterministic behavior on all network speeds.

Imagine that component A is rendered in a tab - You click a button to send a 'GET' request out. It takes 200 ms for the response to come back. So, you are safe to close the tab at any moment knowing that, the machine will be faster than you & the http response is processed and is complete before the tab is closed and component A is destroyed.

How about on a very slow network? You click a button, the 'GET' request takes 10 seconds to receive its response, but 5 seconds into waiting you decide to close the tab. That will destroy component A to be garbage-collected at a later time. Wait a minute!, we did not unsubscribe -- now 5 seconds later, a response comes back and the logic in the destroyed component will be executed. That execution is now considered out-of-context and can result in many things including very low performance.

So, the best practice is to use takeUntil() and unsubscribe from http calls when the component is destroyed.

import { Component, OnInit, OnDestroy } from '@angular/core';
import { HttpClient } from '@angular/common/http';

import { Subject } from 'rxjs';
import { takeUntil } from 'rxjs/operators';

interface User {
  id: string;
  name: string;
  age: number;
}

@Component({
  selector: 'app-foobar',
  templateUrl: './foobar.component.html',
  styleUrls: ['./foobar.component.scss'],
})
export class FoobarComponent implements OnInit, OnDestroy {
  private user: User = null;
  private destroy$ = new Subject();

  constructor(private http: HttpClient) {}

  ngOnInit() {
    this.http
      .get<User>('api/user/id')
      .pipe(takeUntil(this.destroy$))
      .subscribe(user => {
        this.user = user;
      });
  }

  ngOnDestroy(): void {
    this.destroy$.next();  // trigger the unsubscribe
    this.destroy$.complete(); // finalize & clean up the subject stream
  }
}