While HTTP is stateless (https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol), the technologies used to render the html needs a mechanism to deal with the state of the system i.e. whether the user is logged in or what claims the user has. That mechanism could be a function of the framework (e.g. ViewState in Microsoft WebForms), a function of HTML (e.g. local storage or cookies) or a function of a library (e.g. NGRX, React-Redux). Regardless of how the management of state is solved, the fact is that for a majority of production ready, business-centric web applications state is very important.

At HSD we enjoy using the Angular framework for UI focused web applications. Angular, like React, was built with components in mind. That is the page is split up into many smaller components. Components allow the developer to develop Vertical Slices that deal with different functions of the application (e.g. Top Level Navigation, Side Navigation etc). Using this paradigm to build a web application adds a layer of complexity in respect to the communication between the components on the page.

One way of dealing with state in Angular is by using ngrx/store (https://github.com/ngrx/store). In a typical ngrx/store setup we have: Actions,  Reducers, Selects. It’s a good library but the boilerplate code needed for ngrx/store to work can be painful, adding Effects to the mix and the complexity increases.

“NgRX Effects are a awesome approach to observable event streams but they can be painful to construct, read, maintain and teach to other devs. It feels like we need to be an RxJS expert to write them effectively and its really easy to cause unwanted side effects.” – https://medium.com/@amcdnl/why-another-state-management-framework-for-angular-b4b4c19ef664

An alternative approach has been proposed recently and so far I am enjoying using it. The library is called ngxs.

From the ngxs documentation:

“What is NGXS?

NGXS is a state management pattern + library for Angular. It acts as a single source of truth for your application’s state, providing simple rules for predictable state mutations.

NGXS is modeled after the CQRS pattern popularly implemented in libraries like Redux and NGRX but reduces boilerplate by using modern TypeScript features such as classes and decorators.”

Let’s look at building a trivial page that has two buttons that Increment and Decrement a number which is displayed on the page.

The following code assumes a familiarity with Angular CLI and Angular itself.

After initialisation of the new app, we start by creating some actions. Actions are a set of instructions for what we want the application to do.

Then we create the store. The store is a global state manager for the application. It’s the central point for the dispatching of actions and also provides a way to select data slices from the global state. This can be done in three steps:

  1. Create an interface to describe the state that we are interested in.
  2. Create the state and decorate the code with the @State decorator.
  3. Create a class that groups the action listeners and decorate the code with the @Action decorator.

Then we wire the state to the component. To do this we use the Select function. The Select function represents a specific slice of state from the state container.

In this example the slice of state is named count$ and we subscribe to the changes using the subscribe function in RxJS.

Then we create the view.

The only task left is to run the command ng serve from the terminal and if all goes well you will see a website like below.

Hope you’ve enjoyed the first part of the of this series discussing NGXS and in the next part we’ll look at using Actions to interact with external systems.

The final code for this part is here https://github.com/hsdgit/State.Of.Angular.

In the meantime please take the time to read the article Why another state management framework for Angular? and also the NGXS documentation.