-
Notifications
You must be signed in to change notification settings - Fork 47k
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
Eager bailout optimization should always compare to latest reducer #15124
Conversation
This name is a bit more descriptive.
I tried fixing it like this, and it also passed tests: 6670512. Is my fix wrong? If yes, can we add a new case that this naïve fix would fail? |
@gaearon That's essentially the same fix except in yours doesn't account for the render phase updates path. So I think it would break if an earlier state in the same component gets a render phase update, and then a subsequent inline reducer closes over that. I'll see if I can write a test case where that would fail. |
Added additional test that fails if reducer is not updated in the render phase updates branch. |
…acebook#15124) * Eager bailout optimization should always compare to latest reducer * queue.eagerReducer -> queue.lastRenderedReducer This name is a bit more descriptive. * Add test case that uses preceding render phase update
Based on a bug report by @pomber
https://mobile.twitter.com/pomber/status/1106667842844401670
The issue was that the queue contains a reference to the last rendered reducer, but we weren't updating it in all cases, so sometimes it was stale, triggering the bailout incorrectly.
The original bug report (https://codesandbox.io/s/yj605043yv) had an additional bug in it that made it a bit more confusing, which is it did not specify an initial state. I did not include that part in my test case because it wasn't relevant to the actual underlying bug.