-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
feat(router-store): add action creator for root router actions #2272
Conversation
Preview docs changes for 213dace at https://previews.ngrx.io/pr2272-213dace/ |
a365589
to
1005064
Compare
@timdeschryver, I made the changes to the doc. I also made a small diagram for the route-store flow. I think a picture tells more than some text. Looking forward on your reply. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tbh, I have no idea how these actions are used in the wild.
I'm wondering if we also should provide a router action creator, to keep them generic.
This because a const
can't have a generic AFAIK.
This would look as follows:
// allow the flexibility to create a custom router action with a generic
export const createRouterCancelAction = <
T,
V extends BaseRouterStoreState = SerializedRouterStateSnapshot
>() => createAction(ROUTER_CANCEL, props<{ payload: RouterCancelPayload<T, V> }>());
// the default implementation with the default router store state
export const routerCancelAction = createRouterCancelAction<SerializedRouterStateSnapshot>();
Does this make sense?
So the main reason I think we should do this is to have a common Do you agree with this? I don't think we should change the default router reducer in a similar way as in the |
I agree, the reason I mentioned it was for our end-users. The only reason I see to create the router action creators, is for cases where a custom router serializer is used. In these serializers it's possible to add extra meta-data to the router state, which is added to the dispatched action. In the current implementation (without creators), it's possible to define this extra meta-data with the generic on the Action. This can be helpful if the Action is used in, for example, an effect because it will provide a type-safe Action with the extra meta-data, for example you be able to do With the current implementation with the creator functions, this isn't possible anymore and the That being said, I think this PR is good. We can always add the router action creators later if needed, because I'm uncertain if this is use-case is being used. |
Okay, just to be sure, this PR is good for now? 😊 |
For me it is! 👍 |
Great, thanks for your help will make a separate PR for the image that explains the action order. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
we added the action creator for root router actions
What is the current behavior?
Closes #2206
What is the new behavior?
Does this PR introduce a breaking change?
Other information