Quantum NgRx Facades | Sam Julien | #AngularConnect

NgRx facades are terrible! No wait, they're the best thing ever! What the heck is a facade, anyway? You may have heard recently about a topic whizzing around the Angular community: facades in NgRx. But are facades good or bad? Much like the age-old controversy of whether light is a particle or a wave, the answer depends on how you look at them. In this talk, you'll learn what facades are, why you should embrace them, why you should never, ever use them, and how to implement one without making Mike Ryan wake up in a cold sweat somewhere in Alabama.

About Sam Julien

Sam Julien is an Angular GDE, a Content Engineer at Auth0, and the creator of the course UpgradingAngularJS.com. He's also the co-organizer of Angular Portland. When he's not writing or coding, you'll find Sam hiking or camping in the Pacific Northwest.

[wojciechtrawinski]

Nice talk :) However, I've been always perceiving the Facade in a little different way, namely that you should rely on some sort of generic methods exposed by the facade (like turnOnBeams). The reason is that if a simply have generic methods I can easily switch from one state management library to other one. With your solution (having dispatch method) I would have to stick to event-driven state management library. In addition, you created the CollidorFacade which I guess is meant to be used withing the CollidorPage so I can't think of any other place where I could use the facade and take advantage of not repeating myself when dealing with the store.

[dsebastien]

Great talk, thanks Sam! For my current project I've also faced this issue of reusing actions caused by a misuse of facades. Indeed having a dispatch method solves this, but at the same time it makes it impossible to perform other actions as part of the facade when a specific action is called, like directly returning a specific selector. Of course, the method can expose other methods to select specific slices of state, but with action-specific methods, this could be done in one step. For instance, imagine a "loadGames" method in the facade, which would first dispatch the "load_games" action and then directly return the "get_games" selector (e.g., an Observable<Game[]>).


I feel like all that is lacking is actually a "context" for calling those facade actions. If the caller has to provide its "identity" when invoking the facade (or if the facade could derive that information itself), then it could still dispatch specific actions instead of always reusing the same ones. I'm pretty sure that this could provide an even cleaner solution, which would allow to have clear/useful method names and would also avoid the action-reuse issue.


To me, having a single "dispatch" method in the facades pretty much defeats the purpose of having a facade because since that method is generic, it cannot have action-specific behavior and thus is just a pass-through towards the store, so the "abstraction" of the store becomes quite limited.


What do you think?

[danylogudz]

looks more like adapter pattern but not the facade

[kardashevr]

Just when you thought that the NGRX team reduced the boiler plate code in the 8th version, these masochists introduced facades.