35
votes

I got asked by one of my colleagues if we need to unsubscribe from the afterClosed() Observable of a Dialog.

We are using the takeUntil pattern to unsubscribe from all Observables on ngOnDestroy().

this.backEvent = fromEvent(window, 'popstate')
    .pipe(
        takeUntil(this.destroy$)
    )
    .subscribe(
        () => {
            this.navigationService.backClicked = true;
            this.navigationService.navigateBackToDirectoryCenter();
        }
    );

ngOnDestroy()

ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
}

So is it necessary to unsubscribe from afterClosed() Observable?

dialogRef.afterClosed().subscribe(
    (data) => {
            console.log(data);
        }
    },
);

or?

dialogRef.afterClosed()
    .pipe(
        takeUntil(this.destroy$)
    )
    .subscribe(
        (data) => {
            console.log(data);
        },
    );
3
I have never unsubscribed from a dialog after it's closed and nothing has broken (yet). But nice question.Orestis Zekai
NO you don't need to unsubscribe, as it automatically completes.Archit Garg

3 Answers

67
votes

No

You don't need to unsubscribe as the observable itself completes.You can verify the same by adding a finalize block to see whether observable completes itself or not.

import { finalize } from "rxjs/operators";
dialogRef
  .afterClosed()
  .pipe(finalize(() => console.log("completed")))
  .subscribe(data => {
    console.log(data);
  });

And when you will close the dialog, you will see completed in console, this depicts that you do not need to unsubscribe the observable.

5
votes

Good question, just had a look at the docs (https://material.angular.io/components/dialog/overview) , nothing seems to hint towards the need to unsubscribe at all, what you already have should suffice.

2
votes

You usually want to unsubscribe from observables to prevent memory leaks and to prevent errors, when the subscribe block uses this.xxxx component property.

Even though the subscription completes and you do not need to think about a memory leak, you should be aware of the second problem.

The host component that calls dialogRef.afterClosed() might get destroyed while the dialog is still visible. The subscription would emit after close and when you access a component property inside the subscribe block, it would throw an error.

I think it's a rare situation, that the host component get destroyed while a dialog is active, but I wanted point that edge case. An example could be a Floating Button that opens a Dialog but disappears after scroll or other circumstances.