-
Notifications
You must be signed in to change notification settings - Fork 47.7k
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
Fixed a batched-state update bug with getDerivedStateFromProps #12408
Fixed a batched-state update bug with getDerivedStateFromProps #12408
Conversation
Once this PR is approved and merged- (assuming it is)- I'll cut another alpha release with it and the recent context infinite loop bugfix (#12402). |
|
||
let derivedStateFromProps; | ||
if (oldProps !== newProps) { | ||
// In this case, the prevState parameter should be the partially updated state, |
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.
Conceptually, what you're calling prevState
is the work-in-progress state. So your comment here applies to all cases; it's not special.
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.
"in this case" just referred to the update case. The other two invocations of this method are mounting cases. But I'll re-word the comment.
@@ -867,19 +867,11 @@ export default function( | |||
} | |||
} | |||
|
|||
let derivedStateFromProps; |
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.
Why did you change the order of getDerivedStateFromCatch
and getDerivedStateFromProps
? The new order seems correct, just curious what led you to make the change in this diff.
It looks like the order in the "resume mount" path is different now, though. Should be consistent regardless.
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.
Why did you change the order of
getDerivedStateFromCatch
andgetDerivedStateFromProps
?
This was incidental. I changed the order of processUpdateQueue
and getDerivedStateFromProps
. I did that because it seemed easier to get the correct partial state value that way than trying to mess with the update queue and it's memoized vs base state.
It looks like the order in the "resume mount" path is different now, though. Should be consistent regardless.
Fair 👍
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.
One more thing: could you add a test so the order doesn't incidentally change in the future?
} | ||
|
||
const instance = ReactTestUtils.renderIntoDocument(<Parent />); | ||
const element = ReactDOM.findDOMNode(instance); |
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.
Nit: let's not use findDOMNode
. Maybe a ref instead? I know it's just a test, but we should still try to avoid using legacy APIs :D
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.
I confess, I often copy paste an existing test when writing a new one to save a few seconds.
Back to you @acdlite, with the one change you requested. |
Chatted in meat space. Merging! |
Addresses a batched state update bug reported in #12047.