-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
fix inadvertent re-renders when using Component instead of element #10287
Conversation
🦋 Changeset detectedLatest commit: 283aa48 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
packages/router/router.ts
Outdated
detectErrorBoundary?: DetectErrorBoundaryFunction; | ||
enhanceAgnosticRoute?: EnhanceAgnosticRouteFunction; |
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 feel like this name could be clearer, e.g. resolveRouteProperties
, resolveCustomRouteProperties
?
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.
Definitely open to bike-shedding here. I kinda like indicating that this function is what takes us from framework-agnostic to framework-aware. resolveFrameworkAwareRouteProperties
is a mouthful though 😕 . resolveRouteFrameworkProperties
or resolveRouteRenderProperties
maybe?
Do you think the word "resolve" carries an incorrect connotation that this is how route.lazy
stuff gets applied? That's not quite correct since this is a second pass after we apply the route.lazy
props.
Longer term, I could even see a future where we decide that Component/ErrorBoundary
are framework-agnostic enough (in todays component-based framework landscape, and as opposed to element
/errorElement
which felt super react-specific) and maybe we just type them as any
in the router and that would eliminate hasErrorBoundary
entirely. Then we overload the types in the router layer with React.Component
etc.
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 could also be a future flag, but it's an implementation detail of RR and only newly (6.9.0) public API in @remix-run/router
so on the fence as to whether it's worth a formal future flag?
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.
Bikeshedded and currently thinking mapRouteProperties
Co-authored-by: Mark Dalgleish <mark.john.dalgleish@gmail.com>
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
Closes #10283