Common and easy-to-make mistakes when you’re new to NgRx
This post is aimed at newcomers to NgRx.
In the first part of the post, we’ll be creating a new Angular project and we’ll implement a FizzBuzz implementation with NgRx. For the initial setup we’ll use the Angular CLI, and to scaffold the NgRx files we’ll be relying on the NgRx schematics.
The second part of the post will be used to refactor and reason about the implementation of the first part. The goal is to have a more maintainable code base.
Before we start, let’s get everyone up to speed with FizzBuzz. FizzBuzz is a task that prints out numbers incrementally starting from 1, if the number is divisible by three the number get replaced by the word fizz and if the number is divisible by five it gets replaced by buzz. If the number is divisible by both three and five, the word fizz buzz will be printed out.
The output starts as follows:
1, 2, Fizz, 4, Buzz, Fizz, 7, 8, Fizz, Buzz, 11, Fizz, 13, 14, FizzBuzz, 16, 17, Fizz, 19, Buzz, Fizz, 22, 23, Fizz, Buzz, …
Let’s get started! We can create the project using the
ng new command and we’ll install the NgRx packages using the NgRx schematics. These schematics will install the package and will also automate the needed configurations to wire up NgRx correctly.
With the project ready, we can start to implement FizzBuzz. We do this by creating the fizzbuzz reducer, using the reducer schematic.
In the reducer:
- We define the fizzbuzz State, with the counter and the message to print out
- Provide an initial state, to initially load up the start of the application
- Create the reducer function. Inside this function, we modify the state in a pure way — we don’t mutate properties directly on the state. Whenever we want to print out the next output, invoked by the
NEXTaction, we increment the counter and create the message. Inside the
switchstatement, the default case is very important. When the reducer retrieves an action it isn’t responsible for (every reducer gets invoked by any action), we return the state as is. Without the default return case, the state would become
Now that we’ve defined the fizzbuzz state and the fizzbuzz reducer, it’s time to print out the fizzbuzz output. Inside the
AppComponent, we inject the Store to get the fizzbuzz message and to dispatch the
NEXT action to invoke the reducer.
To get the message from the store, we use the
select operator. Because
State is the whole application state, we first have to access the
fizzbuzz state in order to retrieve the
message. This gives us an RxJS stream, consisting of messages. To print the messages out, we use the Angular
To trigger a state change, we have to invoke the fizzbuzz reducer. Because we can’t invoke the reducer directly, we use the
dispatch function. We send the action
NEXT to the store which will invoke the fizzbuzz reducer, resulting in a new message in the message stream.
If we now start the application, we’ll see the fizzbuzz messages! 🎉
Before we walk through the refactoring, I would encourage you to roll up your sleeves first and refactor the current code yourself on StackBlitz.
The first step in the refactoring journey would be to create actions. We do this to remove magic strings, but maybe even more important, to allow action type checking. In this small example, the full power of this step won’t be visible. In larger applications, you’ll notice that TypeScript can infer the action’s properties inside the reducers.
We can create the action by using the action schematic.
The above schematic creates the action file and an example action inside of it, consisting out of an action enum, an action creator, and an action union type. We can modify this to fit our fizzbuzz application as follows:
Now, we can remove the magic string
NEXT inside the fizzbuzz reducer and inside the
For more information about actions see the official docs and a previous post Let’s have a chat about Actions and Action Creators within NgRx.
The problem with the working code is that we hold multiple versions of the same state inside the store state, this can make it hard to maintain over time when the application keeps on growing. That’s why we’re going to extract the fizzbuzz message inside a selector.
Before we can create the selector, we first have to provide a
getter to retrieve the
counter within the fizzbuzz state. When this is done, we can create our message selector to compute derived state.
With the action and the selector created, it’s time to clean up the reducer. This is done by:
- Typing the actions by using the actions union
FizzBuzzActions. This makes sure that the
cases are valid and will also correctly type the action inside the
- Replacing the
Nextstring with the enum
- Removing the
messageproperty from the state, since the message is now derived in the
I’m a big fan of effects and I’m using it to put every piece of logic that isn’t specific to the component’s logic. The most used and known example of this are AJAX requests, but the use cases of effects can be broadened out to everything that is causing your component to become impure.
effects/app.effects.ts file created by the
ng add command, we’re going to move the logic to dispatch the
Next action on every second. For this, we’re using the RxJS
interval instead of the
setInterval method, creating a continuous stream that emits a
Next Action on each time interval. These actions will be dispatched to the store, invoking the reducer that on his turn triggers the
getMessage selector resulting in a re-render with the new message output.
With these steps completed, we can now go back to the
- Remove the dispatch logic
- Use the
getMessageselector — personally, I also prefer removing the Store’s type. You won’t lose type safety because the selector (and its output) is typed. Plus from my experience, the Store’s type can lead to confusion, this is because at runtime it will contain the whole AppState.
If you keep these little tips in mind, each boundary inside the application has its own responsibility. This makes it easier to reason about and easier to maintain in the long run. If something goes wrong you can quickly scope it down to a specific boundary and you immediately know where to look.
- by using this convention, we get rid of a magic string value
- we gain type safety
- we don’t have to write an action more than once, we add a small layer of abstraction and follow the DRY principle
- it makes testing actions easier, we only have to write one test
- maintainability bonus: follow the Good Action Hygiene practice introduced by Mike Ryan
- this will lead to smaller and cleaner reducers
- we have a single point of truth, we don’t have to remember every state property for this state
- we only have to test state mutators
- readability bonus: if the immutable way (using the spread operator) of writing reducers is new and a bit uncomfortable, use Immer to make the transition easier — Clean NgRx reducers using Immer
- don’t pollute the store state, use selectors as queries to create view models
- keep selectors small so they can be used to compose bigger selectors
- since these are just functions that receive state and return some data they are also easy to test
- selectors are highly performant because they memoize (cache) the latest execution so they don’t have to re-execute on every state change
- in-depth bonus: to fully understand the benefits that selectors provide see Selectors are more powerful than you think by Alex Okrushko
- making your components pure, thus predictable, easier to reason about
- fully unleashes the power RxJS provides, e.g. cancel pending requests when needed
- easier to test components, but also provides separated tests for side effects
- architectural bonus: different ways to process actions, Patterns and Techniques by Victor Savkin
To end this post, see the this Blitz for the refactored version.
Please consider supporting me if have you enjoyed this post and found it useful: