Current Complexity with Action Definitions
A standard approach to implementing actions with @ngrx requires defining an enumeration of action types, which map a code identifier to a string, implementation of an action class that derives from Action and the concatenation of each action type into an action union that allows proper implementation of a reducer function to reduce actions and the information they contain into your state.
This is a lot of work required just to add the ability to create an entity. Not only do you need the ability to handle the initial create request, but also deal with the success or failure of that request, at the very least. So each "action" generally tends to trifurcate, and thus the action types and action union code trifurcates as well.
With the release of NgRx 8, several utility functions, factory functions, were introduced and can help reduce some of the "boilerplate" nature of implementing actions, effects and reducers. These new functions are a welcome improvement over prior versions of NgRx...however, we do believe they still fall short of providing the kind of simplified, rapid development experience Auto-Entity provides for entity use cases.
For custom use cases, we are in fact huge fans of the new factory functions in NgRx. They provide a much cleaner approach to using NgRx in general, for actions, effects, etc. Even with automatic entities, applications that fully rely on NgRx for the bulk of the application logic will require many additional actions, effects, selectors, reducers, etc. We strongly encourage their use whenever you do not need boilerplate entity support!
Using the createAction factory, we can reduce the previous boilerplate to the following:
A definite reduction in complexity, and a small reduction in overall code volume. However, actions must still be created in order to handle entity loading/success/failure in NgRx. And, similar sets of actions must be created for each and every entity you need to use in your app.
Once actions are defined, one may then dispatch them using the @ngrx store. This is usually done within Angular container components:
For actions to actually do anything, however, you need more. Your work does not end here. You still need effects, and reducers, to make any of these dispatched actions actually perform useful work and update state.