AngularJS 2.0 From The Beginning - State Management - Day Twenty Three

Debasis Saha
May 02, 2017
8.3k
0
0
Article

In this Angular 2.0 article series, we have already discussed about different types of basic and advanced concepts or features of AngularJS 2.0 like data binding, directives, pipes, service, route, http modules, change detection etc. Now, in this article, we will discuss about State Management concept in AngularJS.

In case you have not had a look at the previous articles of this series, go through the links mentioned below.

For larger Angular applications with a lot of asynchronous activity and where there's a lot of states that are being shared and manipulated across multiple components and modules, managing state can be quite challenging. In a typical application, we're managing things like:

Data that comes from the server and whether it's pending or results in an error
UI state like toggles, alerts and errors messages
User input, such as form submissions, filters and search queries
Custom themes, credentials and localization
Many other types of state

As the application grows, how do we know that a state change in one module will consistently and accurately reflect in other modules? And what if these modifications result in even more state changes? Eventually, it becomes extremely difficult to reason about what's actually happening in your application, and be a large source of bugs.

In Angular, we can solve this problem by using Redux using @ngrx.

What is Redux?

Redux is an application state manager for JavaScript applications, and keeps with the core principles of the Flux-architecture by having a unidirectional data flow in your application. Where Flux applications traditionally have multiple stores, Redux applications have only one global, read-only application state. This state is calculated by "reducing" over a collection or stream of actions that update it in controlled ways.

What is @ngrx?

Redux state managers have been very well received and have inspired the creation of @ngrx, a set of modules that implement the same way of managing state as well as some of the middleware and tools in the Redux ecosystem. @ngrx was created to be used specifically with Angular and RxJS, as it leans heavily on the observable paradigm.

Adding @ngrx to your Project

In your console, run the following command to add @ngrx to your list of dependencies in package.json.

npm install @ngrx/core @ngrx/store --save

If you plan on using the @ngrx/effects extensions to add side-effect capabilities, then also run the following command.

npm install @ngrx/effects --save

Defining Main Application State

When building an application using Redux, the first thing to think about is, "What state do I want to store?" It is generally a good idea to capture all of the application's states so that it can be accessible from anywhere and all in one place for easy inspection.

In the application state, we store things like:

Data received through API calls
User input
Presentation state, such as menu and button toggles
Application preferences
Internationalization messages
Themes and other customizable areas of your application

To define your application state, use an interface called AppState or IAppState, depending on the naming conventions used on your project.

Here's an example.

app/models/appState.ts

export interface AppState {
readonly colors: Colors;
readonly localization: Localization;
readonly login: Login;
readonly projectList: ProjectList;
readonly registration: Registration;
readonly showMainNavigation: boolean;
}

Example Application

In this chapter, you'll be creating a simple counter application using @ngrx. Your app will allow users to increment and decrement a number by one, as well as reset that value back to zero. Here's the AppState that we'll be using throughout the example.

app/models/appState.ts

import {Counter} from './counter';
export interface AppState {
readonly counter: Counter;
}

app/models/counter.ts

export interface Counter {
readonly currentValue: number;
}

Reading your Application State using Selectors

To read your application state in Redux, we need to use the select() method on @ngrx's Store class. This method creates and returns an Observable that is bound to a specific property in your application state. For example, here's how you would select the counter object:

store.select('counter'); // Returns Observable<Counter>

And to fetch the counter's currentValue, we can pass in a string array, where each string plucks a single property from the application state one at a time in the order specified:

store.select(['counter', 'currentValue']); // Returns Observable<number>

While select() allows for several variations of strings to be passed in, it has it' shortcomings - namely you won't actually know if the plucking is working properly until you execute your code. Because of that, select() allows you to select values using functions too, which makes things more type-safe and your selectors will be more refactorable by your IDE.

store.select(appState => appState.counter.currentValue);

Creating a Counter Service

While you could inject Store and select values directly in your Angular components, it's considered to be a best practice to wrap this functionality into separate services. This approach encapsulates all of the selection logic and eliminates any duplication where the selection path is repeated throughout your application.

Let's tie everything together by building out a CounterService example:

app/services/counter.service.ts

import {Injectable} from '@angular/core';
import {Store} from '@ngrx/store';
import {Observable} from 'rxjs/Observable';
import {AppState} from '../models';
@Injectable()
export class CounterService {
constructor(private store: Store<AppState>) {}
getCurrentValue(): Observable<number> {
return this.store.select(appState => appState.counter.currentValue)
.filter(Boolean);
}
}

Because select() returns an Observable, the getCurrentValue() method also applies a filter() to ensure that subscribers do not receive any falsy values. This greatly simplifies the code and templates in your components, since they don't have to repeatedly consider the false case everywhere the value is used.

Actions

Redux uses a concept called Actions, which describe state changes to your application. Redux actions are simple JSON objects that implement the Action interface provided by @ngrx,

export interface Action {
type: string;
payload?: any;
}

The type property is a string used to uniquely identify your action to your application. It's a common convention to use lisp-case (such as MY_ACTION), however you are free to use whatever casing style that makes to your team, as long as it's consistent across the project. The payload property provides a way to pass additional data to other parts of Redux, and it's entirely optional. Here is an example,

const loginSendAction: Action = {
type: 'LOGIN_SEND',
payload: {
username: 'katie',
password: '35c0cd1ecbbb68c75498b83c4e79fe2b'
}
};

Plain objects are used so that the actions are serializable and can be replayable into the application state. Even if your actions involve asynchronous logic, the final dispatched action will remain a plain JSON object.To simplify action creation, you can create a factory function to take care of the repeating parts within your application.

app/store/createAction.ts

import {Action} from '@ngrx/store';
export function createAction(type, payload?): Action {
return { type, payload };
}

The resulting creation of the LOGIN_SEND action becomes much more succinct and cleaner,

const loginSendAction: Action = createAction('LOGIN_SEND', {
username: 'katie',
password: '35c0cd1ecbbb68c75498b83c4e79fe2b'
});

Modifying Application State by Dispatching Actions

Most Redux apps have a set of functions, called "action creators", that are used to set up and dispatch actions. In Angular, it's convenient to define your action creators as @Injectable() services, decoupling the dispatch, creation and side-effect logic from the @Component classes in your application.

Synchronous Actions - Here is a simple example.

app/store/counter/counter.actions.ts

import {Injectable} from '@angular/core';
import {Store} from '@ngrx/store';
import {createAction} from '../createAction';
import {AppState} from '../../models/appState';
@Injectable()
export class CounterActions {
static INCREMENT = 'INCREMENT';
static DECREMENT = 'DECREMENT';
static RESET = 'RESET';
constructor(private store: Store<AppState>) {
}
increment() {
this.store.dispatch(createAction(CounterActions.INCREMENT));
}
decrement() {
this.store.dispatch(createAction(CounterActions.DECREMENT));
}
reset() {
this.store.dispatch(createAction(CounterActions.RESET));
}
}

As you can see, the action creators are simple functions that dispatch Action objects containing more information that describes the state modification.

Asynchronous Actions

This "ActionCreatorService" pattern comes in handy if you must handle asynchronous or conditional actions (users of react-redux may recognize this pattern as analogous to redux-thunk in a dependency-injected world).

app/store/counter/counter.actions.ts

import {Injectable} from '@angular/core';
import {Store} from '@ngrx/store';
import {createAction} from '../createAction';
import {AppState} from '../../models/appState';
@Injectable()
export class CounterActions {
constructor(private store: Store<AppState>) {
}
incrementIfOdd() {
this.store.select(appState => appState.counter.currentValue)
.take(1)
.subscribe(currentValue => {
if (currentValue % 2 !== 0) {
this.store.dispatch(createAction(CounterActions.INCREMENT);
}
});
}
incrementAsync(timeInMs: number = 1000) {
this.delay(timeInMs).then(() => this.store.dispatch(createAction(CounterActions.INCREMENT)));
}
private delay(timeInMs: number) {
return new Promise((resolve) => {
setTimeout(() => resolve() , timeInMs);
});
}
}

In the incrementIfOdd() action creator, we create one-time subscription to the counter's currentValue in the application state. From there, we check to see if it's odd before dispatching an action. In the incrementAsync() action creator, we are delaying the actual call to dispatch(). We created a Promise that will resolve after the delay. Once the Promise resolves, we can then dispatch an action to increment the counter.

Actions that Depend on Other Services

The ActionCreatorService pattern becomes necessary in cases where your action creators must use other Angular services. Consider the following SessionActions service that handles a remote API call.

import {Injectable} from '@angular/core';
import {Store} from '@ngrx/store';
import {createAction} from '../createAction';
import {AppState} from '../../models/appState';
@Injectable()
export class SessionActions {
static LOGIN_USER_PENDING = 'LOGIN_USER_PENDING';
static LOGIN_USER_SUCCESS = 'LOGIN_USER_SUCCESS';
static LOGIN_USER_ERROR = 'LOGIN_USER_ERROR';
static LOGOUT_USER = 'LOGOUT_USER';
constructor(
private store: Store<AppState>,
private authService: AuthService
) {
}
loginUser(credentials: any) {
this.store.dispatch(createAction(SessionActions.LOGIN_USER_PENDING));
this.authService.login(credentials.username, credentials.password)
.then(result => this.store.dispatch(createAction(SessionActions.LOGIN_USER_SUCCESS, result)))
.catch(() => this.store.dispatch(createAction(SessionActions.LOGIN_USER_ERROR)));
};
logoutUser() {
this.store.dispatch(createAction(SessionActions.LOGOUT_USER));
};
}

Review of Reducers and Pure Functions

One of the core concepts of Redux is the reducer. A reducer is a function with the signature (accumulator: T, item: U) => T. Reducers are often used in JavaScript through the Array.reducemethod, which iterates over each of the array's items and accumulates a single value as a result. Reducers should be pure functions, meaning they don't generate any side-effects. A simple example of a reducer is the sum function,

let x = [1, 2, 3].reduce((sum, number) => sum + number, 0);

Reducers as State Management

Reducers are simple ideas that turn out to be very powerful. With Redux, you replay a series of actions into the reducer and get your new application state as a result. Reducers in a Redux application should not mutate the state, but return a copy of it, and be side-effect free. This encourages you to think of your application as UI that gets "computed" from a series of actions in time.

Simple Reducer - Let's take a look at a simple counter reducer.

app/store/counter/counter.reducer.ts

import {Action} from '@ngrx/store';
import {CounterActions} from './counter.actions';
export default function counterReducer(state: number = 0, action: Action): number {
switch (action.type) {
case CounterActions.INCREMENT:
return state + 1;
case CounterActions.DECREMENT:
return state - 1;
case CounterActions.RESET:
return 0;
default:
return state;
}
}

We can see here that we are passing in an initial state (the current number) and an Action. To handle each action, a common approach is to use a switch statement. Instead of each reducer needing to explicitly subscribe to the dispatcher, every action gets passed into each reducer, which handles the actions it's interested in and then returns the new state along to the next reducer. Reducers should be side-effect free. This means that they should not modify things outside of their own scope. They should simply compute the next application state as a pure function of the reducer's arguments. For this reason, side-effect causing operations, such as updating a record in a database, generating an id, etc. should be handled elsewhere in the application, like in your action creators or using @ngrx/effects.

Complex Reducer

Another consideration when creating your reducers is to ensure that they are immutable and not modifying the state of your application. If you mutate your application state, it can cause unexpected behavior. There are a few ways to help maintain immutability in your reducers. One way is by using new ES6 features such as Object.assign() or the spread operator for arrays.

app/models/counter.ts

export function setCounterCurrentValue(counter: Counter, currentValue: number): Counter {
return Object.assign({}, counter, { currentValue });
}

Here, the setCounterCurrentValue() function creates a new Counter object that overwrites the counter.currentValue property with a new value while maintaining the references and values of all of the other properties from counter. Let's update our reducer to utilize this concept,

import {Action} from '@ngrx/store';
import {Counter, createDefaultCounter, setCounterCurrentValue} from '../../models/counter';
import {CounterActions} from './counter.actions';
export function counterReducer(
counter: Counter = { currentValue: 0 },
action: Action
): Counter {
switch (action.type) {
case CounterActions.INCREMENT:
return setCounterCurrentValue(counter, counter.currentValue + 1);
case CounterActions.DECREMENT:
return setCounterCurrentValue(counter, counter.currentValue - 1);
case CounterActions.RESET:
return setCounterCurrentValue(counter, 0);
default:
return counter;
}
}

With each action, we take the existing counter state and create a new state with the updated value (such as counter.currentValue + 1). When dealing with complex or deeply nested objects, it can be difficult to maintain immutability in your application using this syntax. This is where a library like Ramda can help.

Creating your Application's Root Reducer

@ngrx allows us to break our application into smaller reducers with a single area of concern. We can combine these reducers by creating an object that mirrors the application's AppState, where each property will point to one of those smaller reducers.

app/store/rootReducer.ts

import {counterReducer} from './counter/counter.reducer';
export const rootReducer = {
counter: counterReducer
};

Configuring your application

Once you have your reducers created, it’s time to configure your Angular application. In your main application module, simple add the StoreModule.provideStore() call to your @NgModule's imports:

app/app.module.ts

import {BrowserModule} from '@angular/platform-browser';
import {NgModule} from '@angular/core';
import {FormsModule} from '@angular/forms';
import {HttpModule} from '@angular/http';
import {StoreModule} from '@ngrx/store';
import {EffectsModule} from '@ngrx/effects';
import 'rxjs/Rx';
import {rootReducer} from './store/rootReducer';import {CounterActions} from './store/actions';
import {CounterEffects} from './store/effects';
import {AppComponent, CounterComponent} from './components';
import {CounterService} from './services';
@NgModule({
imports: [
BrowserModule,
FormsModule,
HttpModule,
StoreModule.provideStore(rootReducer)
],
declarations: [
AppComponent,
CounterComponent
],
providers: [
CounterActions,
CounterService
],
bootstrap: [AppComponent]
})
export class AppModule {
}

Implementing Components

To demonstrate how to use the CounterService in your components, let's start by building out a small CounterComponent. The component will be responsible for incrementing and decrementing the counter by one, as well as allowing the user to reset the counter to zero.

app/components/counter.component.ts

import {Component, Input} from '@angular/core';
import {Observable} from 'rxjs/Observable';
import {CounterService} from '../services';
import {CounterActions} from '../store/counter/counter.actions';
@Component({
selector: 'counter',
templateUrl: './counter.component.html'
})
export class CounterComponent {
private currentValue$: Observable<number>;
constructor(
counterService: CounterService,
public actions: CounterActions
) {
this.currentValue$ = counterService.getCurrentValue();
}
}

app/components/counter.component.html

<p>
Clicked: {{currentValue$ | async}} times
<button (click)="actions.increment()">+</button>
<button (click)="actions.decrement()">-</button>
<button (click)="actions.reset()">Reset</button>
</p>

The template syntax should be familiar by now, displaying an Observable counter value with the asyncpipe. Any time appState.counter.currentValue is updated by a reducer, currentValue$ will receive the new value and | async will update it in the template. The component also handles some click events. Each click event is bound to expressions that call our action creators from the CounterActions ActionCreatorService.

Modifying AppComponent to become a smart component

First, let's modify our top-level application component to use the CounterService and CounterActions, just as CounterComponent did,

app/app.component.ts

import {Component} from '@angular/core';
import {Observable} from 'rxjs';
import {Counter} from '../../models/counter';
import {CounterService} from '../../services/counter.service';
import {CounterActions} from '../../store/counter/counter.actions';
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent {
counter$: Observable<Counter>;
constructor(
counterService: CounterService,
public actions: CounterActions
) {
this.counter$ = counterService.getCounter();
}
}

Now, our AppComponent is a smart-component, because it's aware of Redux, it's presence in the application state and the underlying services. As with previous examples, we can use the async pipe to obtain the most recent counter value and pass it along to other components within the template. And while we haven't looked at the @Output()'s on CounterComponent just yet, we'll want to delegate those events to our action creators in CounterActions.

app/app.component.html

<counter [counter]="counter$ | async"
(onIncrement)="actions.increment()"
(onDecrement)="actions.decrement()"
(onReset)="actions.reset()">
</counter>

Modifying CounterComponent to become a presentation component

In turn, we need to make the CounterComponent from a smart component into a dumb component. For this, we will pass the data into the component using @Input properties and click events using @Output() properties, removing the use of CounterService and CounterActions entirely.

app/counter/counter.component.ts

import {Component, Input, EventEmitter, Output} from '@angular/core';
import {Counter} from '../../models/counter';
@Component({
selector: 'counter',
templateUrl: './counter.component.html'
})
export class CounterComponent {
@Input()
counter: Counter;
@Output()
onIncrement: EventEmitter<void> = new EventEmitter<void>();
@Output()
onDecrement: EventEmitter<void> = new EventEmitter<void>();
@Output()
onReset: EventEmitter<void> = new EventEmitter<void>();
}

Our child components become much simpler and testable, because we don't have to use the async pipe to work with our state, which removes a lot of pain when dealing with lots of @Input's or the need to use complex expressions with Observables. We can also now simply use core Angular features to emit values whenever a click event happens.

app/counter/counter.component.html