Book Image

Architecting Angular Applications with Redux, RxJS, and NgRx

By : Christoffer Noring
Book Image

Architecting Angular Applications with Redux, RxJS, and NgRx

By: Christoffer Noring

Overview of this book

Managing the state of large-scale web applications is a highly challenging task with the need to align different components, backends, and web workers harmoniously. When it comes to Angular, you can use NgRx, which combines the simplicity of Redux with the reactive programming power of RxJS to build your application architecture, making your code elegant and easy to reason about, debug, and test. In this book, we start by looking at the different ways of architecting Angular applications and some of the patterns that are involved in it. This will be followed by a discussion on one-way data flow, the Flux pattern, and the origin of Redux. The book introduces you to declarative programming or, more precisely, functional programming and talks about its advantages. We then move on to the reactive programming paradigm. Reactive programming is a concept heavily used in Angular and is at the core of NgRx. Later, we look at RxJS, as a library and master it. We thoroughly describe how Redux works and how to implement it from scratch. The two last chapters of the book cover everything NgRx has to offer in terms of core functionality and supporting libraries, including how to build a micro implementation of NgRx. This book will empower you to not only use Redux and NgRx to the fullest, but also feel confident in building your own version, should you need it.
Table of Contents (12 chapters)


NgRx is an implementation of the popular pattern, Redux, that's meant for use with Angular. It is entirely possible to create an Angular application without NgRx. You might even be very successful in doing so. There are situations, though, where Redux can really help; you can get that help by using NgRx.

So, what is Redux and when do we need it? Redux is about adding predictability to your app. Predictability is about knowing who did what to the state in your application.

Single source of truth is a concept that Redux lives up to as it promotes adding all your data to one store. At any given moment, you will be able to tell what state your application is in. This is great if you want to save the state and come back to it (also called rehydration) like you would in a game where you create a save point and later resume your game from that save point.

It's not only about having a single source of truth; it's also about knowing who is allowed to change the content, or the state, of the store. A challenge you often face is that as an application grows, you need to add a lot of views and controllers, you gradually lose the overview of what code affects what state in the application. Redux helps you with this by ensuring that a view can't change the state directly but will have to dispatch actions that represent the intent of how you want the state to change.

Another thing that might happen is that a lot of user interaction kicks off a lot of changes to the state. Some of those actions should lead to immediate changes and some lead to asynchronous actions that will eventually change the state of the application. The important thing at this point is that we ensure that all those changes happen in the right order. Redux helps us with that by queuing up all the actions and ensures that our app changes its state in a predictable way.

A very important aspect of Redux is that when it changes the state, it does not mutate it. It replaces the state with a copy of the old state, but with the latest action applied to it. If we take our game analogy again, imagine that you have a game and you want to add a potion to your backpack. When you do that in Redux, we replace the main character; we replace it with a main character that has a potion in its backpack. The fact that we do things this way makes it easy for us to remember each previous state and return to an earlier state if we need to, which is known as time-travel-debugging. To enable us to replace the previous state with a new state, we are using something called pure functions. Pure functions ensure that we only create a copy of the data instead of mutating it.

There are a lot of benefits to knowing what state your app contains at a given point. However, not all the state in your app will need Redux. It comes down to preference. Some prefer to put all the state in the store, some prefer to put some state in the store, and some other state is fine if it only lives as local state in a specific component. Think of it this way, if you were to restore your app, what state would be okay to lose; the answer may be a drop-down selection made or something else, if anything. Having everything in the store will ensure that you don't, by mistake, make extra Ajax calls if the store already holds the data, so it is a way of helping you with caching as well.