-
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
useSelect: cancel render queue in a more straightforward way #40433
Conversation
Size Change: +1 B (0%) Total Size: 1.23 MB
ℹ️ View Unchanged
|
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 makes sense. Nice little refactoring 👍
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 new queue method makes sense to me, and I love all the nice improvements to the useSelect
hook ❤️
Thanks, @jsnajdr.
P.S.
I think we can remove this warning comment now (original discussion for ref):
gutenberg/packages/data/src/components/use-select/index.js
Lines 241 to 243 in a4da15b
// If you're tempted to eliminate the spread dependencies below don't do it! | |
// We're passing these in from the calling function and want to make sure we're | |
// examining every individual value inside the `deps` array. |
a733319
to
96a393d
Compare
96a393d
to
c05daff
Compare
Hey @jsnajdr I've noticed that this actually started throwing React warnings. You can try by selecting a block and then unselecting it. It seems there's a still some callbacks that are run after a useSelect component is unmounted. |
I think I'll have to re-introduce the
The child has already unsubscribed, but the data store is still looping through the old list of listeners.
|
If we can do that somehow in the future, it would be great, it would allow us to avoid the zombie bug as well (the weird error handling and try/catch we have) |
I confirmed locally that adding the |
When the
useSelect
hook runs in async mode, it defers the store update callbacks using@wordpress/priority-queue
. On certain occasions, it needs to cancel the already scheduled callbacks. Until now, the cancelling was done by setting aisMountedAndNotUnsubscribing
bool flag tofalse
, and then flushing the queue, i.e., executing the scheduled callbacks, while checking theisMountedAndNotUnsubscribing
flag inside the callbacks, making them into noops.This patch introduces a new
cancel
method to@wordpress/priority-queue
, and calls it inuseSelect
when the intent is "cancel". That's more straightforward and easier to understand.The
flush()
andcancel()
methods are analogous to how Lodash names methods to flush and cancel functions returned fromdebounce
orthrottle
:How to test:
Verify that the unit test suite for
useSelect
still passes. Since #40321 the test suite should be sufficiently thorough to verify that a change like this one is OK.