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
Drain entire render queue in a single microtask #1135
Drain entire render queue in a single microtask #1135
Conversation
…e being added to it
I believe this was originally designed to push doubly-nested renders into the queue rather than firing initially because people were using setState() loops for animation. With this change, that would become impossible - I wonder if people are still doing that? |
@developit Ran some tests and it appears that calling |
Honestly I'm split here - when using Promise-based debouncing, this PR is a good improvement. It's when using custom debounce (rAF, rIC or setTimeout) that it seems to matter more. That said, the "animation by looping setState" approach isn't something I would imagine anyone is relying on other than me, and I'm very willing to give that up haha. I actually think we should probably work to land this PR. |
@developit let me know what I can do to help in the way of adding tests or similar. |
oh my goodness it saves 10 bytes too! yay :) |
The previous implementation of the render queue would schedule any render operations that were enqueued as the queue was being processed in the next microtask. This proposed implementation will process even render operations that are enqueued while the queue is being drained as part of the same microtask.
(this is a result of the discussion in #819, where it is common for additional render operations to be enqueued during the render process as a result of a component throwing an error in
render
and an ancestor component callingsetState
in itscomponentDidCatch
method)