Action Mapping in NgRx

[Armenvardanyan95]

When building complex applications with multiple libraries (especially using Nx or other tools like it) that utilize NgRx, it often becomes necessary to interact with Actions from other libraries, which you as a developer often do not want (or even don't have the rights) to modify in any way. For instance, consider this example of two applications, one a todo list, and another a calendar. For this purpose, we have a todo-feature library for its store, reducers, etc, and one for the calendar app. Todos feature exports actions like this:

export const TodosActions = createActionGroup({
  source: 'Todos',
  events: {
    'Load Todos': emptyProps(),
    'Load Todos Success': props<{ todos: Todo[] }>(),
    'Load Todos Error': props<{ error: string }>(),
   // and so on for adding, deleting, etc 
  },
});

And the calendar actions exports similar actions but for calendar events. But here's the catch, the calendar app also shows the todo items from the other app in the calendar view (using the to do end date). This means, that when I open up the calendar app, I essentially have to dispatch 2 actions:

export class CalendarComponent implements OnInit {
  private readonly store = inject(Store);
  events = this.store.selectSignal(selectEvents);

  ngOnInit() {
    this.store.dispatch(EventsActions.loadEvents());
    this.store.dispatch(TodosActions.loadTodos());
  }
}

However, this is considered a bad practice as per the "Avoid dispatching multiple actions sequentially" Rule, with which I wholeheartedly agree. It would be better to have some sort of "event" action like "Calendar View Opened", which would then trigger the respective effects and so on. However, I cannot put that action in either of the store libraries, because, well, it does not belong in the todo library as it is not related to todo items, and it doesn't belong to the events store as it is related to the calendar feature itself and probably belongs in the app itself. I could write an effect in the calendar feature app like the following:

export const loadCalendarData  = createEffect(() => {
  const actions$ = inject(Actions);
  return actions$.pipe(
    ofType(CalendarActions.calendarViewOpened),
    switchMap(() => [
      this.store.dispatch(EventsActions.loadEvents()),
      this.store.dispatch(TodosActions.loadTodos()),
    ]),
  );
}, {functional: true})

But this is also disallowed by the same rule, with which I also kinda agree.

So, this leaves us with very limited options, none of which are really good

1. Modify the todos store lib and introduce an unnecessary dependency between the calendar app and the todos store just for the sake of also loading data for the calendar. Could quickly get ugly if we have more interconnected apps.
2. Segregate the views for events and todos in the calendar app, which could work in some scenarios, but might not be workable at all depending on what the UI actually needs to be. If we definitely want both events and todos in the Calendar component, we cannot choose this option
3. Use the previous example of an effect dispatching both actions, ignore the rule (obviously not preferrable).

So, to counter this, I propose a discussion for a simple "Action Mapping" feature in NgRx, with which we can define "mappings" or "translations" between existing actions, both the ones in our app and the ones imported from elsewhere. This can look simple like this:

providers: [
  provideStore(),
  provideState(eventsFeature),
  provideState(todosFeature)
  provideActionMappings([
    [CalendarActions.calendarViewOpened, EventsActions.loadEvents],
    [CalendarActions.calendarViewOpened, TodosActions.loadTodos],
  ]),
]

With this, dispatching CalendarActions.calendarViewOpened will also mean dispatching TodosActions.loadTodos and EventsActions.loadEvents. We can also provide a way to map the payload of the first action to the result like this:

 [CalendarActions.calendarViewOpened, {
   action: TodosActions.loadTodos,
   payloadMapping: (calendarViewOpenedPayload, loadTodosPayload) => {
     return {limitItems: calendarViewOpenedPayload.limit}; // this will have to match the props signature of the second action
   }
 }],

This allows for many things to be easily refactored in an app that uses NgRx, and a way to easily find which action potentially trigger others, and also helps keep feature stores as segregated as possible (which is not a hard requirement, but is still a good practice).

Pros

1. Easier refactoring: if we want to change the flow of some events in our app, we can simply use an action mapping
2. Easily find relations between actions/events, especially when some actions are imported from another package. I can easily see this becoming very useful while using the router store to "translate" actions like "navigation start" from the router store to actions native to our application like "user navigated to login page" based on some conditional logic.
3. Features remain as segregated as possible, we don't have to worry about bringing some dependency that does not belong in a certain app/lib/feature just because we need an action from a place we cannot modify.

Const

1. Introduces more complexity: I would argue the complexity is not too large, however, this can result in some confusion as to why something is triggered or not. This can be mitigated by some slight changes to the NgRx DevTools.
2. Easy to abuse: this is my main concern - developers might be tempted to create multiple "command" actions and then trigger them via 1 "event" action to avoid breaking the abovementioned rule, instead of refactoring their store to work entirely around "event" actions.

Note: the proposed "syntax" I used in the example is just for illustration purposes, if the community decides this is a worthwhile discussion, we can come up with better approaches

It is also possible that I am missing something, and maybe a more native solution for the problem I described in the beginning exists. Would love to hear other opinions.

[rainerhahnekamp]

Hello Armen 👋,

Why is it not possible to do that in the calendar feature?

export const loadEvents  = createEffect(() => {
  const actions$ = inject(Actions);
  return actions$.pipe(
    ofType(CalendarActions.calendarViewOpened),
    map(() => EventsActions.loadEvents())
  );
}, {functional: true})

export const loadTodos  = createEffect(() => {
  const actions$ = inject(Actions);
  return actions$.pipe(
    ofType(CalendarActions.calendarViewOpened),
    map(() => TodosActions.loadTodos())
  );
}, {functional: true})

If I am not mistaken, that is the recommended approach in the lining rule (maybe a class is better here)

[Armenvardanyan95]

Hi, thanks for your idea! In my opinion, this works in a simpler scenario where I just have these two features, but what if events is also a separate feature? So I have three features like todos, calendar, and events, and todosandevents` stores are used in 3 of these features separately. In this scenario, now lots of implementation details kinda leak through all 3 libraries. Again, there is nothing criminal in doing this, of course, but this seems like a lot of code for what is essentially an implementation detail (for this action do that action).

To be straightforward, this is not a burning issue at all, just something I consider possibly useful

[rainerhahnekamp]

Do you mean you have a set of features where other features depend on them to become activated? Like this?

graph TD;
    AppFeature1-->Todos;
    AppFeature1-->Calendar;
    AppFeature1-->Events;
    AppFeature2-->Todos;
    AppFeature2-->Calendar;
    AppFeature2-->Events;

Loading

If yes, then I would create a core feature which is doing the activation for the three master data features, like this:

graph TD;
    CoreFeature-->Todos;
    CoreFeature-->Calendar;
    CoreFeature-->Events;
    AppFeature1-->CoreFeature;
    AppFeature2-->CoreFeature;

Loading