-
-
Notifications
You must be signed in to change notification settings - Fork 916
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
Enhance getProps
to Extract Dynamic Route Parameters
#1105
base: 5.x
Are you sure you want to change the base?
Conversation
File size impactdist (+6,178 bytes)Overall impact on dist files size
Detailed impact on dist files size
Impact on dist files cache8 files in you users cache are now outdated because their content have changed.
|
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.
Please add tests.
const result = assign({}, customProps, { | ||
name, | ||
mountParcel: mountParcel.bind(appOrParcel), | ||
singleSpa, | ||
route: { |
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.
This new prop would need to be documented with a pull request to https://github.com/single-spa/single-spa.js.org. Please open a pull request with it.
The route
name for the prop is one that should be considered. In react-router, I believe it's called params
rather than route
. I think I'm open to either name, but we should think about it carefully.
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.
The name route
may be good for potential enhancements in the future to keep similar props
under the same namespace. For example, search/query.
What do you think?
const result = assign({}, customProps, { | ||
name, | ||
mountParcel: mountParcel.bind(appOrParcel), | ||
singleSpa, | ||
route: { | ||
get params() { |
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.
I would prefer not using a Javascript getter here, since it has performance implications just for accessing props.route
. Ideally we'd calculate the route params once per URL change rather than every time any code does props.route
. I haven't thought through whether it would be possible to do that, but it's something that should be explored. The toDynamicPathRegexInfo
function is complex enough that I don't want it running frequently
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.
I don't think there's a foul proof native way of listening to URL changes. We may try building route
object whenever navigateToUrl
is invoked.
will it be good enough or we may try something else?
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.
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.
@dsfx3d I don't think navigateToUrl
is a good solution because it is not the only or even primary way people use to change the URL. I think it should be done in an event handler that fires when the URL changes. Just my $0.02.
This PR improves the getProps function by enabling it to extract dynamic route parameters and include them in the final props object. These modifications enhance the functionality of single-spa applications by providing developers access to dynamic route parameters within the app props.
resolves #744