-
Notifications
You must be signed in to change notification settings - Fork 4.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
Block Editor: Clear toolbar timeout by ref on unmount #20546
Conversation
Related: #14845 |
Size Change: -31 B (0%) Total Size: 866 kB
ℹ️ View Unchanged
|
81ac91c
to
d6024dc
Compare
@@ -59,6 +59,8 @@ export function useDebouncedShowMovers( { | |||
[ isFocused ] | |||
); | |||
|
|||
useEffect( () => () => clearTimeout( timeoutRef.current ) ); |
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.
If you want to uun this on unmount, you need to add []
as a second argument of useEffect
otherwise it runs on each render.
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.
Good catch Riad, I see it explained in React docs:
The default behavior for effects is to fire the effect after every completed render. That way an effect is always recreated if one of its dependencies changes.
If you want to run an effect and clean it up only once (on mount and unmount), you can pass an empty array ([]) as a second argument. This tells React that your effect doesn’t depend on any values from props or state, so it never needs to re-run. This isn’t handled as a special case — it follows directly from how the dependencies array always works.
https://reactjs.org/docs/hooks-reference.html#conditionally-firing-an-effect
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.
Fixed in 02eb218.
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.
Good catch, thanks for spotting @youknowriad, and for the fix @gziolo .
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 still could see a similar error but triggered from a different place:
The only way I could reproduce is by doing the following:
- Add a few Paragraph blocks.
- Save the draft and refresh the page.
- Remove the block and observe JS console in Dev Tools.
It only gets triggered for the first block removed. It works perfectly fine after that when removing any blocks.
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 found a similar but apparently a different issue. Let's merge this fix for now 🚢
I removed 5.4-related project and issue assignment. As far as I can tell, this was only introduced as of #19344, so it doesn't need to be backported. Let me know if I'm wrong. |
I know that issue existed forever, but it might another one I shared as well 🤷♂ I guess, it's fine to wait for WP 5.5 rather than work on two independent fixes. Unless you think it might have some really negative consequences. |
Well, the specific file changed was only introduced as of #19344. If there's a related issue, I expect it might need its own patch, since this one won't apply cleanly. |
This pull request seeks to resolve a warning which can occur in some circumstances where a block toolbar component is unmounted while its deferred hide/show movers behavior is scheduled. The scheduling was not being cleared when the component unmounts.
Testing Instructions:
I originally observed this when running the meta box end-to-end tests in #20544 when building in development mode (where the React warnings logged in development mode will flag an end-to-end test failure).
You can confirm the following fails in master:
Then change to this branch. Running those commands again should show success.