Auth0 Home Blog Docs

NgRx Facades: Pros and Cons

angular
#1

Learn about the facade pattern, why you may or may not want to use one with NgRx, and how to create a facade.

#2

How did you like this post? Please share any comments or feedback with us on this thread :slight_smile:

#3

Facades encapsulate the complexity of using and combining NgRx Selectors (aka queries). The beauty of NgRx Facades, however, is how it enables code compression in the view layers.

The books-page.component.ts can easily be compressed to this:

@Component({
  selector: 'abl-books-page',
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `

    <mat-card>
      <mat-card-title>My Collection</mat-card-title>
      <mat-card-actions>
        <button mat-button raised color="accent" (click)="facade.loadBooks()">Reload Books</button>
      </mat-card-actions>
    </mat-card>

    <abl-book-preview-list [books]="books$ | async"></abl-book-preview-list>
})
export class BooksPageComponent implements OnInit {
  books$: Observable<Book[]> = this.facade.allBooks$;

  constructor(private facade: BooksFacadeService) {  }
}

See my Gist for more details: http://bit.ly/2QVau2l

1 Like
#4

That’s great! Thanks for your input Thomas!

#5

I’m not sure I agree that using facades is a productivity win. It’s takes time to write and maintain all that extra code for each of your stores, and since your facade’s methods should be a simple mapping to your store’s selectors and actions (if you’re putting a lot of logic inside facade methods, something’s gone wrong) then you’re not saving much effort using the facade’s method vs. calling the store directly in your components. E.g. this.myFacade.fetchData(); isn’t really much less typing than this.store.dispatch(new FetchDataAction());. Overally, it’s more likely to be a productivity loss, as you have more code to write, maintain and navigate, and for new developers to grok when coming to the project.

The only legitimate argument I see for facades is abstracting away your use of NgRx from your components. Personally, I don’t find that convincing enough. If you’re doing things right in an NgRx app, your components should be extremely dumb, as all your logic should be happening in your reducers, selectors and effects. Your components become little more than a thin bridge between the HTML in the template and the store. As such, their existence and implementation depends entirely on your use of NgRx and it’s not as if you can stop using NgRx and keep using these components. Nor it is the case that there are genuine alternative Redux implementations that you’re potentially going to use in an Angular app.

#6

Thanks for reading and for your input, Jon!

#7

We use the facade pattern, simply because it makes testing easier. When you’re testing the component mocking the store starts becoming messy but by using the facade pattern all you need to do is mock the actual service itself which makes testing significantly easier.

However we do expose a disptach() method that’s used by all of our facade services that the component uses to dispatch actions to the store, so all we’re really doing is putting the facade in between the store and its selectors

1 Like