Redux introduction with NgRx (part 2): Redux Principles

Redux introduction with NgRx

This article is part of the serie of articles that you may want to read before starting this one.

Here is the summary:

1. Store & Application State
2. Redux Principles (you’re here)
3. Redux core concepts
4. NgRx high level introduction
5. NgRx syntax explained

Redux principles

Redux can be described in three fundamental principles.

1. Single source of truth
2. State is read-only
3. Pure functions update state

Single source of truth

One state tree inside the Store

Unlike other state management systems like Flux that has multiple stores, Redux enforce only one global store through all the application. You may have created multiple services in charge of each part of your application state and end up injecting these services in multiple components. With Redux, you centralize all that in the same place. It is then easier to think about and to maintain.

Predictability, maintainability

Manipulations of your state are done in a predictable way. Meaning, given the same previous state and the same manipulation, you will always get the same new state. That make the maintainability and the way we use and think of the Store much easier.

Universal apps (SSR)

SSR stands for Server Side Rendering. On the server we can create this initial state object of the Store and pass the representation of the state tree down from the server on initial load. Which means that we don’t have to bootstrap the application and make all the HTTP calls to get the right state of the application, we already have it on the first paint.

State is read-only

The state is read-only, meaning that we can only access it. We can’t do overwrites or any actions to mutate it or directly change the information. We will need to dispatch an Action for that.

Immutable update patterns

Immutable data cannot be changed once created, leading to much simpler application development, enabling advanced memoization and change detection techniques with simple logic.
Immutable patterns enforce the fact that your data should be serializable and any manipulation on these data should not mutate the current state.

Testing & debugging

When it comes to debugging, because Redux enforce immutable manipulations and the use of pure functions, we can have a more simple approach to testing a single Store. The predictability of the store allows us then to use different tools to help us debug the application like the Time travel debugging, exporting states, viewing tree representations.

Derive properties from state

We can have a large tree for our application and we will “slice” it with some functions to focus on one particular branch that is needed for a specific component rendering the data.

Dispatch actions to change the state

Action is a simple function to call a function to do a change in the state. Actions are payloads of information that send data from your application to your store. They are the only source of information for the store. Actions are unique.

Pure functions update state

A pure function is easy to test because for the same input it will always return the same output. It doesn’t mutate or access properties outside of its own scope. Pure function are predictable.

• Reducers are pure functions;
• Reducers are triggered by Action types: Reducers scans action types to know what type of manipulation is required on the application state;
• Reducers return new state: after doing the manipulation of the state in an Immutable way, we always return the new application state. Then, the new state is now part of the application state and all the components depending on it will get notified and can render the new data.

See you in the next part “Redux core concepts”!