Fix unstable_useBlocker key issues in strict mode #10573
Conversation
🦋 Changeset detectedLatest commit: adacb89 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 |
| @@ -935,8 +936,9 @@ let blockerId = 0; | |||
| export function useBlocker(shouldBlock: boolean | BlockerFunction): Blocker { | |||
| let { router } = useDataRouterContext(DataRouterHook.UseBlocker); | |||
| let state = useDataRouterState(DataRouterStateHook.UseBlocker); | |||
| let [blockerKey] = React.useState(() => String(++blockerId)); | |||
There was a problem hiding this comment.
Moved this increment into a side effect to be compliant with StrictMode. Fetchers probably have a similar issue but they don't need to put anything like a blocker function into an internal router cache so it doesn't end up causing any user-facing issues.
| updateState({ blockers: new Map(router.state.blockers) }); | ||
| let blockers = new Map(state.blockers); | ||
| blockers.set(blockerKey!, IDLE_BLOCKER); | ||
| updateState({ blockers }); |
There was a problem hiding this comment.
Avoid mutating the state Map directly
|
@brophdawg11 is this PR hasn't added to the latest version (v6.13.0)? |
|
Correct - it will be available in |
|
🤖 Hello there, We just published version Thanks! |
|
🤖 Hello there, We just published version Thanks! |
|
Good afternoon! I'm wondering if this patch will be available in the next release or if there are any estimates at all as to when it would be released. Thank you |
| () => () => router.deleteBlocker(blockerKey), | ||
| [router, blockerKey] | ||
| ); | ||
| React.useEffect(() => { |
There was a problem hiding this comment.
I believe this introduced a useEffect loop since setBlockerKey is used in the dependency array and changed in the same effect.
Fix issues with internal blocker
keygeneration inStrictModeCloses #10073
Closes #10144
Also strips the
basename(if present) from thecurrentLocation/nextLocationwe expose out to the user to matchuseLocationbehavior. This was discovered as part of #10550 (comment)