NgRx — Best Practices for Enterprise Angular Applications

May 30, 2018 0 Comments

NgRx — Best Practices for Enterprise Angular Applications

 

 

This article is not intended to be a tutorial on NgRx. There are several great resources that currently exist, written by experts much smarter than me. I highly suggest that you take time and learn NgRx and the redux pattern before attempting to implement these concepts.

The following represents a pattern that I’ve developed at my day job after building several enterprise Angular applications using the NgRx library. I have found that most online tutorials do a great job of helping you to get your store up and running, but often fall short of illustrating best practices for clean separation of concerns between your store feature slices, root store, and user interface.

With the following pattern, your root application state, and each slice (property) of that root application state are separated into a RootStoreModule and per feature MyFeatureStoreModule.

This article assumes that you are building an Angular v6 CLI generated application.

Before we get started with generating code, let’s make sure to install the necessary NgRx node modules from a prompt:

npm install @ngrx/{store,store-devtools,entity,effects}

Create a Root Store Module as a proper Angular NgModule’s that bundle together NgRx store logic. Feature store modules will be imported into the Root Store Module allowing for a single root store module to be imported into your application’s main App Module.

  1. Generate RootStoreModule using the Angular CLI:
ng g module root-store —-flat false —-module app.module.ts

2. Generate RootState interface to represent the entire state of your application using the Angular CLI:

ng g interface root-store/root-state

PLEASE NOTE: You will come back later on and add to this interface each feature module as a property.

Create feature store modules as proper Angular NgModule’s that bundle together feature slices of your store, including state, actions, reducer, selectors, and effects. Feature modules are then imported into your RootStoreModule. This will keep your code cleanly organizing into sub-directories for each feature store. In addition, as illustrated later on in the article, public actions, selectors, and state are name-spaced and exported with feature store prefixes.

In the example implementation below we will use the feature name MyFeature, however, this will be different for each feature you generate and should closely mirror the RootState property name. For example, if you are building a blog application, a feature name might be Post.

Depending on the type of feature you are creating you may or may not benefit from implementing NgRx Entity. If your store feature slice will be dealing with an array of type then I suggest following the Entity Feature Module implementation below. If building a store feature slice that does not consist of a standard array of type, then I suggest following the Standard Feature Module implementation below.

  1. Generate MyFeatureStoreModule feature module using the Angular CLI:
ng g module root-store/my-feature-store --flat false --module root-store/root-store.module.ts

2. Actions — Create an actions.ts file in the app/root-store/my-feature-store directory:

3. State — Create a state.ts file in the app/root-store/my-feature-store directory:

4. Reducer — Create a reducer.ts file in the app/root-store/my-feature-store directory:

5. Selectors — Create a selectors.ts file in the app/root-store/my-feature-store directory:

6. Effects — Create an effects.ts file in the app/root-store/my-feature-store directory with the following:

  1. Generate MyFeatureStoreModule feature module using the Angular CLI:
ng g module root-store/my-feature-store --flat false --module root-store/root-store.module.ts

2. Actions — Create an actions.ts file in the app/root-store/my-feature-store directory:

3. State — Create a state.ts file in the app/root-store/my-feature-store directory:

4. Reducer — Create a reducer.ts file in the app/root-store/my-feature-store directory:

5. Selectors — Create a selectors.ts file in the app/root-store/my-feature-store directory:

6. Effects — Create an effects.ts file in the app/root-store/my-feature-store directory with the following:

Now that we have created our feature module, either Entity or Standard typed above, we need to import the parts (state, actions, reducer, effects, selectors) into the Angular NgModule for the feature. In addition, we will create a barrel export in order to make imports in our application components clean and orderly, with asserted name-spaces.

  1. Update the app/root-store/my-feature-store/my-feature-store.module.ts with the following:

2. Create an app/root-store/my-feature-store/index.ts barrel export. You will notice that we import our store components and alias them before re-exporting them. This in essence is “name-spacing” our store components.

Now that we have built our feature modules, let’s pick up where we left off in best practice #1 and finish building out our RootStoreModule and RootState.

3. Update app/root-store/root-state.ts and add a property for each feature that we have created previously:

4. Update your app/root-store/root-store.module.ts by importing all feature modules, and importing the following NgRx modules: StoreModule.forRoot({}) and EffectsModule.forRoot([]):

5. Create an app/root-store/selectors.ts file. This will hold any root state level selectors, such as a Loading property, or even an aggregate Error property:

6. Create an app/root-store/index.ts barrel export for your store with the following:

Now that we have built our Root Store Module, composed of Feature Store Modules, let’s add it to the main app.module.ts and show just how neat and clean the wiring up process is.

  1. Add RootStoreModule to your application’s NgModule.imports array. Make sure that when you import the module to pull from the barrel export:
import { RootStoreModule } from ‘./root-store’;

2. Here’s an example container component that is using the store:

Once we have completed implementation of the above best practices our Angular application structure should look very similar to something like this:

├── app
│ ├── app-routing.module.ts
│ ├── app.component.css
│ ├── app.component.html
│ ├── app.component.ts
│ ├── app.module.ts
│ ├── components
│ ├── containers
│ │ └── my-feature
│ │ ├── my-feature.component.css
│ │ ├── my-feature.component.html
│ │ └── my-feature.component.ts
│ ├── models
│ │ ├── index.ts
│ │ └── my-model.ts
│ │ └── user.ts
│ ├── root-store
│ │ ├── index.ts
│ │ ├── root-store.module.ts
│ │ ├── selectors.ts
│ │ ├── state.ts
│ │ └── my-feature-store
│ │ | ├── actions.ts
│ │ | ├── effects.ts
│ │ | ├── index.ts
│ │ | ├── reducer.ts
│ │ | ├── selectors.ts
│ │ | ├── state.ts
│ │ | └── my-feature-store.module.ts
│ │ └── my-other-feature-store
│ │ ├── actions.ts
│ │ ├── effects.ts
│ │ ├── index.ts
│ │ ├── reducer.ts
│ │ ├── selectors.ts
│ │ ├── state.ts
│ │ └── my-other-feature-store.module.ts
│ └── services
│ └── data.service.ts
├── assets
├── browserslist
├── environments
│ ├── environment.prod.ts
│ └── environment.ts
├── index.html
├── main.ts
├── polyfills.ts
├── styles.css
├── test.ts
├── tsconfig.app.json
├── tsconfig.spec.json
└── tslint.json

It’s important to remember that I have implemented these best practices in several “real world” applications. While I have found these best practices helpful, and maintainable, I do not believe they are an end-all be-all solution to organizing NgRx projects; it’s just what has worked for me. I am curious as to what you all think? Please feel free to offer any suggestions, tips, or best practices you’ve learned when building enterprise Angular applications with NgRx and I will update the article to reflect as such. Happy Coding!


Tag cloud