[Fiber] Fix to call deferred callbackQueue even if updates are aborted - #9634
Conversation
58e55c3 to
871540f
Compare
| inst.setState({text: 'bar'}, () => callbackList.push('text')); | ||
|
|
||
| // Flush part of the work | ||
| ReactNoop.flushDeferredPri(20 + 5); |
There was a problem hiding this comment.
Can you add an assertion to make sure the update processed, but wasn't committed yet? Maybe by passing an updater function to setState instead of a plain object.
acdlite
left a comment
There was a problem hiding this comment.
Thanks! The fix looks good. Fix the test and I'll merge.
|
@acdlite Thanks! I've added an assertion for that. |
|
What happens if this gets aborted and begins many times? This mutation of something that we received from the outside looks suspicious to me: https://github.com/facebook/react/pull/9634/files#diff-58ab36183b601ad6f7c27ed4c7d96278R468 It just to be ok because knew we always started with a fresh array but now we don't. Won't we just keep adding things to it? |
Hmm I don't think so. When we begin work on a queue, we advance the But I agree this is a bit confusing now. I've cleaned this up a bit in the branch I'm working on. |
|
Thanks!!
I'll add a test for this if necessary. |
react#9634) * Fix to call deferred callbackQueue even if updates are aborted * Add an assertion to make sure the update processed, but wasn't committed yet
Currently, setState callback has never been called when the update is interrupted.
This PR is fixed it and added a test for reproducing it.