Introduction
This is the first in a series of articles about building reactive applications in Angular using NgRx state management. I want to begin by laying out my personal relationship with NgRx and introduce an example application that we will use throughout the series. You should already be familiar with common NgRx concepts to get the most out of these articles. In later articles, I will share the good and bad things I have learned about state management and illustrate best practices for NgRx.
The GitHub Repository is available on: https://github.com/rainerhahnekamp/ngrx-best-practices
If you prefer watching over reading, here is the video version:
A long-awaited solution for state management
Since the year 2000, I have been working with heavy-based JavaScript applications. Before you ask, in 2000 we used to call it DHTML and all you had was Visual InterDev. A JavaScript framework did not exist. I always tried to get my hands on the cutting-edge frameworks of that time: Dojo, ExtJs, AngularJS.
I always felt that something was wrong about the way I dealt with data - especially when the data was used in multiple places and a change happened in one of those places. How do you keep the data synchronised?
I came up with functions that notified the relevant parts, I reloaded the whole page after a database update and I did even further uglier things I can't and don't want to remember anymore.
No wonder, I immediately got excited when I heard about the Flux architecture and that it was the solution for that particular problem. It also had a quite catchy name: State Management.
Three years have passed since then. And what should I say? I haven't been disappointed at all!
Why should you use state management?
Many people are wondering whether or not state management is overkill for their application. I have a clear opinion on that: No. As soon as we have multiple components that deal with the same state, we should use state management. Some projects may not need it but I see them as a minority. In my experience, the need for state management happens very quickly.
When it comes to coding state management, I like NgRx. It improves the structure of my applications. Every element of it has its responsibility and place. This allows me to quickly find my way around. And not just me. The same applies for new developers. As long as they know NgRx, they can become productive really fast. Last but not least, I am not making the same mistakes all over again. NgRx provides best practices. I can safely rely on its baked-in expertise.
By saying that NgRx would add benefit for most applications, I don't mean that we should put state management into every corner of our application. When we have a state that only applies to a single component, we shouldn't use NgRx. There are exceptions to that rule though but they will be handled in an upcoming article.
So what's the catch then? We need to be aware that state management adds a lot of boilerplate to our code base. That shouldn't frighten us. As the overall code base grows, the benefits will quickly outweigh the costs.
Due to NgRx’s strict approach and design, it feels kind of inflexible and clunky in some use cases. But we can overcome this. We can rely on best practices. Some are part of this series. That's why you probably are still reading, aren’t you?
Introducing Eternal: demonstrating NgRx best practices
For the sake of simplicity, we have a simple CRUD application for a customer entity. We show a list of customer entries and provide a form to add or edit such a customer. The entry itself is of type Customer which has the following interface.
In NgRx, we have actions for load, update, add and delete. Since backend communication is required they come in the usual pairs, like "load"/"loaded". The effects handle the communication with the backend and we also have selectors.
Only two components are required. One component lists the customers and the detail component provides the functionality to add or edit an entry. The detail form also contains a delete button.
Before we start...
However you might think of it when you start using state management, you will soon stumble upon some use cases where the official documentation leaves you in no-man's land. I hope that the collection of best practices in this series will help you a little bit.
If you are already a seasoned NgRx user, I still hope that there are one or two things you can take away. Even if you are a veteran and say "there wasn’t anything new for me" then I would be happy to hear your comments or maybe a best practice or pattern you find is missing in my list.
Next Article: Part 1 - Cache & Load Status