When does the callback inside the setter function of the useState hook execute?

[nelvko]

The React documentation describes the setter function of the useState hook as follows:

1. React waits until all code in the event handlers has run before processing your state updates.
2. React queues this function（callback inside the setter） to be processed after all the other code in the event handler has run.
3. After the event handler completes, React will trigger a re-render.During the re-render, React will process the queue.Updater functions run during rendering.

Here is the reference address of the official documentation

Here's the pseudo code for the test:

function handleClick() {
  console.log('start')

  setCount(count => {
    console.log('set');
    return count + 1;
  })

  console.log('end')
}

According to the official React documentation, when handleClick is triggered, it first prints "start", then it puts the callback that include "console.log('set')" into the queue (without executing it), then prints "end". After all the synchronous code in the event handler handleClick has finished running, the functions inside the queue will be executed.

In theory, the printing order should be "start", "end", "set".
However, in practice, the printing order was "start", "set", "end".

documentation provides an example where the functions inside the setCount are all queued up, not just the return value. This means that the console.log statements inside the callback functions are also queued up.

Why is the actual print order different from what I understand?

[MeenuyD]

I tried it, but the answer came out to be correct as per the documentation.

[nelvko]

I tried it, but the answer came out to be correct as per the documentation.

Really?Here 's my real code

When i click the button first time,then

but click second and more time then it's correct

It confuses me!!

[MeenuyD]

I think so the actual print order is different because React doesn't guarantee the order of execution of the functions in the queue. According to the official React documentation, "React may batch multiple setState() calls into a single update for performance" which is the concept of batching, which means that the queued functions may not be executed in the order they were added.

In your example, the callback function passed to setCount is queued to be executed after the synchronous code in handleClick has finished running. However, React may choose to execute the queued function before the console.log('end') statement, which explains why the actual print order is "start", "set", and "end".

[rickhanlonii]

The timing for when the callback is called is not guaranteed. We may call it at any time, which is why it must not contain side effects. For example, in your sandbox the first ordering you're seeing is due to an optimization we do when there are no other updates queued, where we eagerly compute the next state and bail out if the state hasn't changed: https://github.com/facebook/react/blob/4cd7065665ea2cf33c306265c8d817904bb401ca/packages/react-reconciler/src/ReactFiberHooks.js#L3013

Importantly, even though we compute the state at this point, we don't apply these updates at that time. The update is still deferred to the same time (after the 'end' log, when the handler exits), even though we computed the state earlier.