AiA 260: NgRx, The Mystical Machine, with Wes Grimes
In this week’s episode of Adventures in Angular the panel has fun interviewing Narwhal rocks star and NgRx expert, Wes Grimes. Wes starts by sharing how he got started in NgRx. In a previous company, Wes was the lead architect for a project that had need of a state management solution, so it was his job to figure out how to use NgRx. While figuring it out he created a structure for using NgRx and used that structure to write a blog article about best practices for NgRx.
This blog article took the world by a storm and now has over 200,00 views. People are now building libraries and courses based on his article. The panel has a little considering the possible searches that lead people to his article. Jennifer Wadella shares some of the weirder searches that have led people to her posts. After their fun, the panel tries to get back on track.
This article thrust Wes into the world of helping people understand NgRx, what he calls a mystical machine. He explains how this article was only the beginning of learning NgRx and that he is currently working on revising that first post. The main point covered in the article was how to organize the store and how to store it in the file system. It walks through creating angular modules for each slice of the store. The second point is covers heavily is the use of barrels.
The biggest problem Wes see people run into in NgRx is they do not know where all their actions are. He shares the solution he uses for this problem, using a public API to group actions so they are easier to find. The panel expresses their frustration with the hard time the CLI has with barrel files. Wes explains why this is a common problem and shares a solution.
The panel asks for other gotcha’s to watch for when using NgRx. Wes explains how and what developers miss out on when they fail to use selectors to their fullest. When selectors are used correctly and completely developers receive all the benefits of the testing they do on NgRx. The other benefits are builtin memoization and reusability.
Another gotcha he warns against is using facades before fully understanding NgRx. This really fires up the panel, who then debates the use of facades in NgRx. Aaron Frost expresses his opinion that NgRx isn’t for everything and that by using facades you may not need to use NgRx. Wes explains that the large companies he works for are already committed to NgRx as their solution and he advises them not to use facades.
Wes explains the downsides of using NgRx, the first is when developers jump in before they understand it and back themselves into a corner. Another downside is the upfront investment cost when learning NgRx.
The panel jumps in wondering what Wes thinks of hiding those developers unfamiliar in NgRx with a facade. Wes explains how in doing this the team would be compromising architecture in order to avoid teaching developers to use NgRx properly. He clarifies that he doesn’t think facades are bad but in order to use them correctly in NgRx developers must first understand how NgRx works. Aaron explains why when working with developers unfamiliar with angular he advises them not to learn NgRx right away.
Wes shares how he has seen developers misuse facades. When using a facade it entices developers to hop back and for between imperative and declarative code. Aaron jumps in and explains that imperative code in reactive programming is very bad. He invites listeners to go out and learn more about this because it is very important to understand.
The panel considers strategies to help teams code reactively. Wes recommends requesting data from the server. This pattern is straight forward to implement and handles a lot of the common use cases in the store. Aaron suggests turning off default change detection, doing so will force the programmers to code reactively. Another way suggested is to structure teams separating concerns.
The episode ends with Wes sharing his experience joining the NgRx core team by working in the documentation, filling in gaps that he found. He also shares what will be coming to NgRx. The platform will be expanding beyond just state management, supplying reactive libraries for angular. They are also getting ready for an experimental release of NgRx component.
- Aaron Frost
- Brian Love
- Jennifer Wadella
- Shai Reznik
- Alyssa Nicoll
- Wes Grimes
Adventures in Angular is produced by DevChat.TV in partnership with Hero Devs
- Sentry use the code "devchat" for 2 months free on Sentry small plan
- Angular Bootcamp
- NgRx — Best Practices for Enterprise Angular Applications
- The Facade of NgRx Facades
- Building with Ivy: rethinking reactive Angular | Mike Ryan | #AngularConnect 2019
- RxJS: A Better Way To Write Frontend Applications - Hannah Howard - JSConf US 2018
- Complex Features Made Easy With RxJS - Ben Lesh
What is the biggest problem people run into when using NgRx.
They do not know where all their actions are.
What does Wes's article on best practice for NgRx cover?
The main point covered in the article was how to organize the store and how to store it in the file system. It walks through creating angular modules for each slice of the store. The second point is covers heavily is the use of barrels.
Why does Wes advise against the use of facades in NgRx?
When using a facade it entices developers to hop back and for between imperative and declarative code.
What are some strategies to help developers code reactively in NgRx?
Wes recommends requesting data from the server. This pattern is straight forward to implement and handles a lot of the common use cases in the store. Aaron suggests turning off default change detection, doing so will force the programmers to code reactively. Another way suggested is to structure teams separating concerns.