Use of @Action Decorator in Provider Class #4
Conversation
bastikempken
changed the title
|
HI @bastikempken, thanks a lot for your contribution! Looks very good imho, why is the PR still in |
|
|
||
| const delegate = (stateContext: StateContext<any>, actionParam: any) => | ||
| providerPropertyDescriptor.value.apply(provider.prototype, [stateContext, actionParam]); | ||
|
|
There was a problem hiding this comment.
I think we need to clarify what happens when attachActionProvider and attachAction provide handlers for the the same ActionType. For example an ActionA could be provided by attachAction and within the ActionProvider of attachActionProvider.
There was a problem hiding this comment.
Make sense, do you have an idea how we can implement it? I think it is possible to check the information stored under META_KEY on the store class if an action is already present before adding. This is a more general inspection, not explicitly to avoid duplication caused by the redundant use of attachAction and attachActionProvider. There could also be a duplicate action which is also provided within a regular store class.
What is the error handling in ngxs/store when an action is provided twice in the same store class?
There was a problem hiding this comment.
@duffleit Friendly Reminder :)
|
Is there anything anyone can do to get this in motion again? This would be great to have. |
|
Any update? |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Action can be provided with higher order functions.
Issue Number: #2
What is the new behavior?
Action can be provided with higher order functions and with the use of the
@Actiondecorator.Does this PR introduce a breaking change?