-
Notifications
You must be signed in to change notification settings - Fork 4.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 issue where changing the id of the recursion provider can result in focus loss #42916
Conversation
Size Change: +105 B (0%) Total Size: 1.27 MB
ℹ️ View Unchanged
|
I thought about leaving a deprecated version of Those two plugins always come up in searches and seem to bundle the whole of the block editor. I'm not sure they're actually using the API. |
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.
It's too bad to lose the nicely coupled hook, but I can't think of decent alternatives, and this seems like a sensible change overall. I trust your judgment. :)
What?
Fixes #39044
Why?
useNoRecursiveRenders
has an issue where it can cause a 'remount' of a child element. The underlying DOM elements are removed and re-added, which can cause side-effects like focus loss.This happens because the hook returns a
RecursionProvider
component, but it doesn't always return the same reference to the component. When theuniqueId
argument changes, a new function reference is returned forRecursionProvider
.During the reconciliation phase, React thinks this function with a different reference is a completely new component, so the DOM updates aren't optimized in the way they are when the component is the same across renders.
How?
The API is changed. There's now a hook
useHasRecursion
and a providerRecursionProvider
that are exported.The key difference is that both need to passed the same
id
, so there's a small amount of extra work for the implementor.Testing Instructions
I couldn't find a way to add automated tests that show this problem, but I'll keep trying.
Here's a way to test manually, but it involves cherry-picking a commit to exploit the problem:
Reproduce the issue in
trunk
trunk
and cherry-pick commit 6e40ab0git reset --hard origin/trunk
to remove the cherry-picked commit.Test that the issue is solved in this branch
Screenshots or screencast
Before (when 6e40ab0 is applied)
Kapture.2022-08-03.at.17.41.12.mp4
After (when 6e40ab0 is applied)
Kapture.2022-08-03.at.17.36.43.mp4