-
Notifications
You must be signed in to change notification settings - Fork 49k
Batch subupdates caused by any state update #1363
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
Conversation
len === dirtyComponents.length, | ||
"Expected flush transaction's stored dirty-components " + | ||
"length (" + len + ") to match dirty-components array " + | ||
"length (" + dirtyComponents.length + ")." |
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.
Could use single quotes and %s here for consistency?
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.
Thanks, fixed.
With this, multiple setState calls triggered by a componentDidUpdate handler (or similar) will be batched together, regardless of if the original setState call was in a batching context. I also cleaned up some inconsistencies with the order of component updates and callbacks in situations where one component's update directly causes another to update. Fixes facebook#1147. Helps with facebook#1353 and facebook#1245 as well, though doesn't completely fix them yet. Test Plan: grunt test
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
Batch subupdates caused by any state update
Counterpart to facebook/react#1363.
Counterpart to facebook/react#1363.
Counterpart to facebook/react#1363.
Counterpart to facebook/react#1363.
With this, multiple setState calls triggered by a componentDidUpdate handler (or similar) will be batched together, regardless of if the original setState call was in a batching context.
I also cleaned up some inconsistencies with the order of component updates and callbacks in situations where one component's update directly causes another to update.
Fixes #1147 and #983. Helps with #1353 and #1245 as well, though doesn't completely fix them yet.
Test Plan:
grunt test
Depends on #1362 and #1358.