RFC: Add "createActionGroup" function to Store package

[brandonroberts]

Long ago, Mike Ryan proposed an API for creating a group of actions with a single function. Today if you're using NgRx Store, you define a set of actions as:

export const loginSuccess = createAction('[Auth API] Login Success', props<{ userId: string, token: string }>());
export const loginFailure = createAction('[Auth API] Login Failure', props<{ error: string }>());
export const logoutSuccess = createAction('[Auth API] Logout Success', props());
export const logoutFailure = createAction('[Auth API] Logout Failure', props<{ error: string }>());

This API would shorten the syntax to:

export const AuthActions = createActionGroup('Auth API', {
    'Login Success': props(),
    'Login Failure': props(),
    'Logout Success': () => { },
    'Logout Failure': (error) => ({ error }),
});

const a = AuthActions.loginSuccess({ user: { name: 'Mike' } });
const b = AuthActions.loginFailure({ error: new Error() });
const c = AuthActions.logoutSuccess();
const d = AuthActions.logoutFailure(new Error());

Reference Tweet: https://twitter.com/MikeRyanDev/status/1308209467834671104
TypeScript Playground: https://bit.ly/2Hb6r2s

[yharaskrik]

Yes please!!

[GregOnNet]

Hi,

to me the syntax looks not really shortened.
I see the following pros and cons of providing the function, mentioned in the description.

Pros

• A group adds semantic and context to its items.

Cons

• The nesting of code is increased
  • To me, this often means harder to read
  • What should the reader focus on? Is it more important to understand the group or do we want to see at a first glance how the respective Action is shaped (type, payload).
• The string literal types here add a level of indirection that need to bee understood by the developer: 'type to function name'
• Now there are two API entry points creating actions that could be mixed

Other thoughts

• The first parameter of createActionGroup seems to be the prefix of each Action of the group.
  • I would prefer being more explicit here (e.g. createActionGroup({ prefix: '[Auth API]' }, ...)

[tomastrajan]

I really love the suggestion!

The great advantage would be the standardization on the consumer side, eg before some consumers imported individual actions while others chose to namespace it using import * as SomeNonconsistentAlias from '...';

With the proposal, consumption of actions could be standardized across all consumers 👍👍👍

[moniuch]

In order to encourage a better action hygiene, I would see the following possible:

export const AuthActions = createActionGroup('', {
    'Login Success': props(),
    'Login Failure': props(),
    'Logout Success': () => { },
    'Logout Failure': (error) => ({ error }),
});

export const AuthActionsFromPage1Facade = createActionSource('[Page1] Auth API', AuthActions);
export const AuthActionsFromEffect = createActionSource('[Effect] Auth API', AuthActions);

// ... more action sources

which in devtools would result in actions like [Page1] Auth API Login or [Effect] Auth API Logout Success

[markostanimirovic]

I'd go with the following signature:

export const AuthApiActions = createActionGroup({
  source: 'Auth API',
  events: {
    'Login Success': props<{ userId: string; token: string }>(),
    'Login Failure': props<{ error: string }>(),
    'Logout Success': emptyProps(),
    'Logout Failure': (error: Error) => ({ error }), 
  },
});

[tomalaforge]

I like the design. As @tomastrajan said, it will standardize the way people refer to action in different codebase.
And will concat namespace object and action in one function.

But the mapping between the name and the function is harder to read. Well detailed action's description like ' Load User, Todo List And Assignees ' won't be advised.

[aboudard]

Does that mean that it would replace createAction method or just be added ? For the sake of standard, it would be better to replace, but that would be a massive job of migration for some apps.
Anyway, I like the idea and the syntax.

[timdeschryver]

createAction won't be removed.
For more info see #3381 where @markostanimirovic is implementing createActionGroup.

[brandonroberts]

#3381 has landed, so locking this conversation in favor of issues for future bugs/features