Open bastikempken opened 4 years ago
@sebastian1607 This is an interesting proposal. The ability to add @Action handlers dynamically is something we will be looking into for v4.
Are you able to achieve what you want with the attach-action labs plugin that Max mentioned?
@markwhitfeld the attach-action labs follows the same idea. I mentioned the idea there and the maintainer likes it, too. I will provide the feature with a pull request to the labs repo. Would be great to see @action handlers on v4.
Hi there, first of all thanks for this cool library!
This should be a kind upvote for the proposed solution from @sebastian1607 ;)
The request in this issue is exactly what we want to achieve too. https://github.com/ngxs-labs/attach-action nearly does what we want except the strong relation due to the attachAction(...)
function (which seems to be a complete list of actions in the state class).
We'd rather prefer a losely coupled version with a syntax like this in a completely separate class:
@Action(ActionClass, StateClass) // state class should establish the linkage to the store
someAction(ctx: StateContext<StateClass>, action: ActionClass) {
...
}
Help others (Google) to find this issue: "NGXS separate actions into different classes", "NGXS different files for actions", "ngxs add actions dynamically" ๐
I like the idea from @PendelinP too, this will reduce a lot complexity of state class.
Currently exits a pull request for the mentioned lab repo we hopefully could finish soon https://github.com/ngxs-labs/attach-action/pull/4
Relevant Package
This feature request is for @ngxs/store.
Description
A solution to provide state actions from additional provider classes.
Describe the problem you are trying to solve
We used the ngxs library and were very satisfied with all the given features. In some cases we had larger state classes, we didn't want to divide into further states because of the high cohesion of the stored data. This classes mostly consist of actions and their implementations of state mutations. We were looking for an idea to share the actions across multiple classes without splitting the state. We thought about a solution called
ActionProvider
which works as follows:Within the
ActionProviderService
the actions of theSomeActionProviderClass
will be merged to the actions ofStateClass
.Describe the solution you'd like
Of course the solution above isn't very API compliant, but maybe it could be a possible feature request? The
@State
decorator could be extended as shown below:I'm really interested in feedback if it is worth to work on a feature request or otherwise if there are other existing library features for the described use case.
Thx in advance