Skip to content
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

Merged
merged 5 commits into from Aug 17, 2018

Conversation

rpetrich
Copy link
Contributor

@rpetrich rpetrich commented Jun 5, 2018

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 calling setState in its componentDidCatch method)

@coveralls
Copy link

coveralls commented Jun 5, 2018

Coverage Status

Coverage remained the same at 100.0% when pulling 3c17e3e on rpetrich:drain-in-single-microtask into 73866a4 on developit:master.

@developit
Copy link
Member

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?

@rpetrich
Copy link
Contributor Author

@developit Ran some tests and it appears that calling setState inside render just busy-loops the browser inside Promise microtasks unless options.debounceRendering = requestAnimationFrame (or similar) is set. Similarly, CSS transitions don't appear to be triggered by updating a transition-enabled CSS property as a result of setState inside render. Still, it makes more sense to preserve the existing behaviour if it was specifically chosen—would you prefer I close this PR and add tests to validate this?

@developit
Copy link
Member

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.

@rpetrich
Copy link
Contributor Author

rpetrich commented Jul 6, 2018

@developit let me know what I can do to help in the way of adding tests or similar.

@developit developit self-requested a review July 18, 2018 15:01
@developit developit self-assigned this Jul 18, 2018
@developit
Copy link
Member

oh my goodness it saves 10 bytes too! yay :)

@developit developit merged commit 30b13c4 into preactjs:master Aug 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants