Allow to specify action name with custom prefix in actions schematics.

[stefanoww]

Currently, when generating action it's always prefixed with the "load", so that when I provide action name as "DeleteUsers", I will end-up with following action within generated file "loadDeleteUsers". It will be nice to have a possibility to generate action with the custom name without "load" prefix. In my case it would be "deleteUsers", "deleteUsersSuccess" etc. What's more I think it would be great to have an option to add actions to the existing file.

If accepted, I would be willing to submit a PR for this feature

[X] Yes (Assistance is provided if you need help submitting a pull request)
[ ] No

[brandonroberts]

Being able to define a prefix seems reasonable to me. We've discussed generating actions into an existing file before, but I think its quicker to copy an existing one, than to type out a command to do the same thing.

[stefanoww]

In context of creating only 3 actions it's might be faster to copy, but also only in specific cases. When at the beginning of creating a state you know that you will need more than 3 actions, it's faster to just prepare command and replace only actions name. What's more I think it could be nice to have a single schematic which will create action, reducer and effects by the single command and add all of them to the specified state and that might be some further step.

[brandonroberts]

@stefanoww you mean like the @ngrx/schematics:feature schematic? It generates everything wired up together. It's been there for a while

[stefanoww]

@brandonroberts Yea, I have been thinking about something similar to the feature schematics (maybe extended with possibility to generate action, reducer, effect by one command in the already generated feature). What's more currently despite generating it, you can not work on it with any other schematics from NgRx. So I would propose to create additional schematics which will allow us to generate: actions, reducers, effects for the existing files. At the beginning I would propose to start with change of the way how the feature schematics works. In my opinion it's should works much closer to the nrwl/nx schematic https://nx.dev/latest/angular/guides/misc-ngrx

[timdeschryver]

I agree with @brandonroberts here.

Adding actions to an action file might be reasonable, but what's the benefit of adding new actions to reducers and effects?
For me this can get out of hand really quick, because:

• not all actions need to be handled by a reducer or an effect (or both), so you would need to remove the generated the code?
• in an event-driven architecture, the action might be used in different reducers/effects
• not everyone uses the same file structure, so you would have to provide an additional reducers and effects path?
• you would still have to add logic to the reducer/effect, because these will be empty?

@mateuszbasinski proposed a way to declare multiple actions at once (instead of the current 3 actions) in #3025.
I think that his proposal might be what we're looking for here?

[stefanoww]

At the beginning I think that idea which @mateuszbasinski proposed is great. Then maybe in new PR we should respect that in the feature schematics as well.

@timdeschryver
What I have been thinking about is a possibility to have a schematic which allows you to work on the generated feature and create additional action, reducers and effects within it (as it's creates initially). As you said we can do it only in the specific conditions where the structure is quite predictable for us and files are in the same directory (grouped or not, what's more we might also provide some best practices of keeping the feature files close to each other instead to have them spread across all of the application scopes). I think the most features are kept in similar structure to the nx example. I agree that handle all the effects and reducers across the app is not a good idea and will be problematic (but also possible). Additional it will be nice to add an facade option to the feature schematics, it's seems to be somehow a standard.