Background Pic by Barn Images on Unsplash

If you’ve used ngrx, the reactive extensions library for Angular, you are probably familiar with the fact that the suite of @ngrx packages has a store-devtools scoped package that provides a way to debug your state store and dispatched actions. And if you have used the store-devtools you are probably familiar with the fact that you need to import the result of a call to StoreModule.instrument() in your root Angular NgModule after you import the store in order to wire up the store-devtools to your app.

Note: Examples are for @ngrx/store-devtools version 4.0.0 and above

This is great for dev time. But when it comes time to build for production we don’t want that instrumentation in the NgModule that we ship. Now we can solve this in a few different ways. We could have a different NgModule that we bootstrap for dev and for prod, or we could have a helper method that returns an array of imports based on some configuration.

But if we are using the Angular CLI there is an easy way to tackle this. We can make use of the built in environment support. A new project generated by the Angular CLI comes with 2 environment files out of the box, environment.prod.ts and environment.ts , that will be used when serving/building for prod and dev respectively.

environment.prod.ts

export const environment = {

production: true,

}

environment.ts

export const environment = {

production: false,

}

Use environment to conditionally wire up store devtools

We can add a property to that environment const that can be an array of imports that we want to add to our root Angular NgModule and leave that empty for the prod version:

environment.prod.ts

export const environment = {

production: true,

imports: []

}

And then put the instrumentation in the one for the dev version:

environment.ts

import { StoreDevtoolsModule } from '@ngrx/store-devtools'; export const environment = {

production: false,

imports: [

StoreDevtoolsModule.instrument({maxAge:5})

]

}

Then we can hop over to our single root Angular NgModule for our application and use the environment.imports property we set up:

app.module.ts

import { BrowserModule } from '@angular/platform-browser';

import { NgModule } from '@angular/core';

import { AppComponent } from './app.component';

import { StoreModule } from '@ngrx/store';

import { environment } from '../environments/environment'; @NgModule({

declarations: [AppComponent],

imports: [

BrowserModule,

StoreModule.provideStore(/* reducer here */),

// Note that you must instrument after importing StoreModule

environment.imports

],

bootstrap: [AppComponent]

}) export class AppModule { }

Because the Angular CLI handles swapping in the appropriate environment file pre-build we are able to leverage that environment const to get things included in our app. And not only things, but typed things like class types that we need to bring in via an import statement. This is super powerful for not only situations like this with the @ngrx/store-devtools, but for many other cases we may need to handle in our Angular applications.