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

[eunjios]

I understand from several issues (#20817 #28287) that React implements an eager bailout for state updates to optimize performance. So I ran some tests with simple examples, and I had some questions about calling the state setter function multiple times for a single event. Below is a detailed explanation of that.

React version: 18.0.0

Steps To Reproduce

1. Initialize the state using useState hook:

const [number, setNumber] = useState(0);

2. Define click event handlers that call setCount multiple times:

// case 1
const handleClick = () => {
  setCount(0);
  setCount(0);
  setCount(0);
};

// case 2: includes changes
const handleClick = () => {
  setCount(0);
  setCount(1);
  setCount(0);
}

3. Click the button to trigger the event handler.

Link to code example: CodeSandbox

The current behavior

The two cases behaved differently when the button was clicked. In the first case, the parent component did not render at all, and of course, its child components did not render either. In contrast, in the second case, only the component rendered. (Child components did not render.)

I'm wondering why the parent component re-renders in the second case when the state is eventually set to 0 (to initial state). Does the parent component have to start the rendering process to figure out if it can quit early? Why?

The expected behavior

Since React batches updates for an event, it seems to be more efficient to compare only the last update and the previous state? In other words, shouldn't it be possible to avoid re-rendering the parent component for the second case as well?

My understanding of the internally implemented code might be incomplete, so please let me know if there are any errors or misunderstandings in my explanation.

[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.

[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.)

[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 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.