Bug: Eager bailout when calling the state setter function multiple times about react

[markerikson]

My general assumption here would be:

• In the first case, all of the values match the original, so there is never a render queued thanks to the bailout
• In the second case, one of the values does not match the original, so at that point a render is queued. That can't be canceled or undone, so the last setState(0) doesn't change anything about that.

[markerikson]

I've tried to trace the internals of the early bailout logic a couple times. Tbh it's really complicated, and I don't remember the exact details.

Based on that behavior description, here's my best guess at what happens:

• First click: normal render queued, parent and child render.
• Second click: render queued. React renders the parent component, but sees that the queued state change of 3 matches the existing state, and no other components were marked as dirty for this render pass. React bails out of the render pass as soon as the parent is done, without recursing down and no components are committed.
• Third click: something extra did get saved as part of the second render pass. This time around, React checks that extra value during the setNumber(3) call, sees that the values are the same, and bails out without even scheduling a render.

[eunjios]

@markerikson

Thank you for your comment. It is helpful to understand. However, I'm still having trouble understanding this specific case:

const [number, setNumber] = useState(0);
const handleClick = () => { 
  setNumber(3);
}

In this code, when the button is clicked for the first time, both the parent and child components are rendered (as expected). Then, on the second click, only the parent component is rendered. And from the third click on, no components are rendered.

This part is very confusing for me in understanding eager bailouts. (I tried to understand it by reading your posts, and it was very helpful, but I'm still having trouble.)

from react.

[eunjios]

@markerikson

Thank you so much for the detailed explanation! It was really difficult to understand the internal logic by tracing the implementation code, but now I understand it.

[github-actions]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[github-actions]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!