-
Notifications
You must be signed in to change notification settings - Fork 404
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🚀[FEATURE]: Action Providers #1618
Comments
@sebastian1607 This is an interesting proposal. 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 We'd rather prefer a losely coupled version with a syntax like this in a completely separate class:
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 ngxs-labs/attach-action#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
The text was updated successfully, but these errors were encountered: