Optimizing NGRX for WebStorm

The following approach is no longer recommended. NgRx has since introduced Action creators which is much simpler to use.

Over the years I have spent developing software, I have come to understand the benefits of tailoring my code to maximize IDE features. By making small stylistic changes, you can be more productive.

This article aims to provide you with tips to improve your NGRX workflow with WebStorm. If you are new to NGRX, there are plenty of useful resources out there to get you started. This article assumes prior knowledge of NGRX.

1. Defining Action Type: Prefer Enum over Constants

Enum speeds up my programming workflow in WebStorm compared to using constants. With WebStorm, I can generate the case statements on the fly. If you added new Enum entries, WebStorm will allow you to generate the missing case statements.

2. Naming Action: Prefer Matching Action Name with Enum Entry

The naming of your actions is irrelevant in WebStorm. WebStorm can infer the action type dynamically when you are using a switch case statement.

Personally, I prefer to name the Action class the same as the enum entry. This way I can add a new action fast by copy pasting the code.

3. Prefer Grouping Actions for Reducer

I always like to group the actions under one type, so that it’s easier to use with reducers.

Note that I left the semicolon on a new line. I do this to speed up adding a new entry — Press CMD+D to duplicate a line and copy paste.

4. Use TS namespace to Group Actions

Finally, as your project grows, it’s common to use the same action but with different prefix. For example, FormSubmitted is a valid action name for any part of the app that deals with form submissions. Conceptually, I want to use it the following way:

this.store$.dispatch(new fromOnboardingActions.FormSubmittted())

This way, it’s clear the action and the origin of the action being dispatched.

The recommended approach is import * as ‘fromActions’. However, using this approach requires me to write the import statements manually. WebStorm has an incredible auto-import feature, and it’s a waste not to use it.

Next option would be to group the Action creators like so.

export const fromActions = {
   GetCurrentUserRequested,
   GetCurrentUserSucceeded,
   GetCurrentUserFailed,
   GetCurrentUserUpdated
}

By doing this, we can start typing the keyword fromActions, and WebStorm would be able to find the right file to import. While this solves the auto import problem, it causes typecasting problem in effects.

Luckily, we can take advantage of TypeScript namespace keyword. While TS doesn’t recommend doing this, but I feel like this use case qualifies namespace usage.

To reiterate why you shouldn’t try to namespace your module contents, the general idea of namespacing is to provide logical grouping of constructs and to prevent name collisions. Because the module file itself is already a logical grouping, and its top-level name is defined by the code that imports it, it’s unnecessary to use an additional module layer for exported objects.

https://www.typescriptlang.org/docs/handbook/namespaces-and-modules.html

Secondary benefit of namespace is that it allow you to split the actions across many files if you file is getting long.

Closing Thoughts

These four small adjustments had big impact on my productivity. Give this a try and let me know what you think.