My First Experiences with the NGRX Store

Martin Džejky Jakubik
4 min readNov 12, 2017

--

A simple NGRX effect

Recently, I decided to start a new Angular project 🤘. As a part of learning new things, I wanted to try all the modern Angular and frontend goodies 🎁. Besides RxJS, I also added NGRX to the project. This was my first time using NGRX in an Angular application and my first time using Redux at all. Here are my thoughts after some time spent working on the project.

Boilerplate Code

The first thing that struck me is how much boilerplate code is required to get up and running. I put several items into the store and almost all of them have 4 files associated with them:

4 files for each item in the store

The file names are pretty self-explanatory. Almost all the data I put into the store has these 4 files (some don’t have effects so that file is not necessary). I like it because it maintains the same structure across the project but it means that often I have to duplicate some code. However, I don’t think this repetition can be reduced much. It would only introduce chaos and bad readability 💥.

This is also specific to the project. Basically, most of the data I put into the store is immutable. It only requires 2 actions — Fetch and Set. The Fetch action is used in an effect to fetch data from the server, which in turn uses the Set action to update it in the store. The only exception in this project are the alerts and the loading state. Alerts are an array of messages which can be added and removed one-by-one. Loading is just a number that is increased when some asynchronous action starts and decreased when it ends.

Working with Redux

Until now, I’ve been used to two-way bindings and Angular triggering Angular’s change detector (I’m using OnPush strategy). It took me a while to switch into RxJS and streams mindset. For those of you that haven’t worked with streams yet, here’s a basic overview. If you want more, here’s a great starting point.

Redux means that the data flows only in one direction, from the store to your views. All your application state is in the store, which is an Observable. You select slices of this state in a component (or a service and pass it to a component) and you also get an Observable which is the stream of data. You can transform this stream in many ways thanks to RxJS operators. Finally, you use this stream in a component template and pipe it through the async pipe to get access to the latest value.

When you want to change this data, you dispatch an action to the store (possibly with its own data called payload). This action is than used by the reducer functions to produce a new state (which is then put into the store). You can also use effects to perform asynchronous tasks on actions and then return new actions.

Data flowing in one way

All this requires that you think differently about the data and the state of your application. It is no longer in your services and your components, scattered all around the application. It is only in the store, the single source of truth. You then pass this data into your components and transform it however you need. In my experience, this makes the components much simpler than when they needed two-way bindings and the change detector. By the way, you no longer need to manually trigger change detection even in components which use the OnPush strategy because Angular knows Observables.

Slicing the State in Services

You can inject the NGRX Store anywhere in the application and select data from it. However, I found that keeping store manipulation in services only nicely encapsulates the logic in one place. The components then inject the service and get the data from it. You can apply common state transformations in the service too and then reuse it across the components. Also, the service is used as a facade pattern so when you want to use a different solution than NGRX, you only have to change the services and not the components.

Next Up

This post is a part of series where I describe what I’ve learned on a fresh Angular project using NGRX and RxJS 📚. In the next post, I’ll be describing my experiences with a new HTML format that Stanislav Kucharik brought to Exponea. If you like this post, make sure to 👏 and 👍 it and follow me for more great content about Angular, frontend development, and Exponea 🎉.

--

--

Martin Džejky Jakubik
Martin Džejky Jakubik

Written by Martin Džejky Jakubik

Frontend developer @ Exponea. Writing about things I learn along the way.

No responses yet