Tomas Trajan 🇨🇭

Posted on Oct 7, 2018 • Originally published at Medium

The Ultimate Answer To The Very Common Angular Question: subscribe() vs | async Pipe

#angular #typescript #javascript #webdev

Most of the popular Angular state management libraries like NgRx expose application state in a form of a stream of state objects. This is usually implemented with the help of RxJS Observables.

The state updates get pushed to the components which react by re-rendering their templates to display the most recent version of the application state.

There are multiple ways in which it is possible to consume this observable stream of state updates by the components, the two most popular being:

Using the subscribe() method and storing the state on the component instance, todos$.subscribe(todos => this.todos = todos)...
The | async pipe unwraps the state object directly in the component’s template, <li *ngFor=”let todo of todos$ | async”></li>...

I have been thinking about this question and related trade-offs for quite some time now. I was mostly in favor of using subscribe() but couldn’t really point out exact reasons why.

Top comments (8)

Stephen Chiang • Oct 7 '18

I was thinking...if I wanted to do some operation in a component based on a boolean stream, I am forced to subscribe so that I can call the the operation when the right boolean value is received right?

I would have to go from:

this.foo$ = this.store.pipe(select(foo));

to:

this.foo$ = this.store.select(state => {
      this.foo = state.store.foo;
      if (this.foo) {
        this.operationOnFoo();
      }
    });

Is this a correct assumption?

Tomas Trajan 🇨🇭 • Oct 7 '18

You can also do this.fooExists$ = this.store.pipe(select(foo), filter(foo => !!foo)); then you can also this.fooExists$.subscribe(operation). But why do you have to call something for every foo? Can't it be implemented using ngrx @Effect() ?

Stephen Chiang • Oct 7 '18

I only need it to happen once and only one component is listening for it... Sort of like this component telling a sibling component that it is ready to do something... So I thought an effect would be Overkill, plus I'm not calling a new Action, the operation happens internally to the listening component.

Stephen Chiang • Oct 8 '18

Would i need to manually unsubscribe in OnDestroy if I did it this way (not @Effect) as you have described?

Tomas Trajan 🇨🇭 • Oct 8 '18

Yes, whenever you do explicit .subscribe() call, you are automatically responsible to call .unsubscribe(). Even better would be to use .pipe(takeUntil(onDestroy$)) which is declarative ;)

Stephen Chiang • Oct 8 '18 • Edited

awesome, thanks!

so then I would also need to do this, right?

ngOnDestroy() {
    this.onDestroy$.next(true);
    this.onDestroy$.unsubscribe();
  }

Tomas Trajan 🇨🇭 • Oct 8 '18 • Edited

ngOnInit() {
   this.source$.pipe(takeUntil(onDestroy$)).subscribe()
}

ngOnDestroy() {
    this.onDestroy$.next(true);
    this.onDestroy$.complete()
}

CHeers!

Stephen Chiang • Oct 7 '18 • Edited

I have been using subscribe in ngOnInit and creating a subscription manager to unsub in OnDestroy which was ok because of couldn't definitely find out which way was better, but then just before this article came out I learned that using the async pipe handled the unsub for me, and now one learned it's also more performant so now I'm trying to use that as much as possible these days. Thanks for this article! I'm excited about the growing presence of angular articles here on Dev.

DEV Community

The Ultimate Answer To The Very Common Angular Question: subscribe() vs | async Pipe

Top comments (8)

Read next

Part 3: C# Fundamentals: Operators and Expressions

Top 11 Web Hosting Powerhouses for 2025: Affordable, Lightning-Fast, and Ready to Perform!

Next.js Interview Mastery: Essential Questions 61-70 (Part 7)

When Scalability Meets Spectacle: Lessons from Netflix's Tyson-Paul Fight Crash