🤯Incredible phenomenon: strange execution order before and after setState

[lovetingyuan]

const [data, setDate] = useState(0);

function handleEvent() {
  Promise.resolve().then(() => {
    console.log(4)
  })
  console.log(1)
  setData(() => {
    console.log(2)
  })
  console.log(3);
}

So, if the output order of the code above is 1, 2, 3, 4, that's normal and expected. In fact, most of the time, the output is indeed 1, 2, 3, 4. However, during development, I occasionally observed the output order as 1, 3, 2, 4, where 1, 3, and 2 were printed almost immediately one after another, followed by 4 a few milliseconds later.

This completely challenged my understanding of JavaScript's execution order. Aren't microtasks supposed to be the highest-priority mechanism executed right after a macrotask? What technique is React using here?

BTW, My application runs within the CEF framework, using Chrome version 124 (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 AIAgent/3.0.3.7161).

[lovetingyuan]

console log:

source code:

[jheisonnovak]

The behavior you're observing is indeed interesting, but I need to clarify a few misconceptions about what's actually happening here.

The normal and expected order is 1, 2, 3, 4, and here's why:

1. console.log(1) - executes immediately (synchronous)
2. setData(() => { console.log(2) }) - the updater function executes immediately when called
3. console.log(3) - executes immediately (synchronous)
4. console.log(4) - executes in the next microtask (after all synchronous code)

The occasional reordering to 1, 3, 2, 4 is not caused by React's batching mechanism. React's state updater functions (setData(() => {...})) execute immediately when called - they're not deferred.

The anomalous behavior is likely caused by:

• Development environment optimizations - Dev tools and React DevTools can interfere with execution timing
• JavaScript engine optimizations - V8 and other engines may optimize code execution in development
• React's development mode checks - Additional validation and debugging code in development builds
• Browser debugging tools - Console timing can be affected by DevTools being open

React's batching affects when re-renders happen, not when updater functions execute. The updater function itself runs synchronously to calculate the new state value. Microtasks (like Promise.resolve().then()) always execute after the current synchronous code completes, which is why console.log(4) consistently appears last.

[lovetingyuan]

I've disabled devtools and stopped using console.log (instead opting to push data into an array of global variables),
yet the result remains the same—the global variable still shows [1, 3, 2] after printing. This rules out your first and last points.

Also, I haven't enabled Strict mode, and I'm not entirely sure what special behaviors React might have in development mode.
I disagree with your second point: the JavaScript engine cannot detect whether you're in development or production mode. Even if it could, the engine would still strictly follow the language specification and wouldn't apply any special behaviors or optimizations.

One additional note: this case isn't reproduced directly in the Chrome browser itself—I'm using CEF (Chromium Embedded Framework), which embeds the Chrome rendering engine (Chrome 124). I'm not sure if that could make a difference.

If setData executed the provided callback immediately, it would be impossible to get the result [1, 3, 2].

[lovetingyuan]

I think I understand the reason now—the callback of setState isn't always invoked "synchronously"(execute immediately).
This is exactly what happens in the case of 132. When execution finishes inside the effect (at this point, 1 and 3 are printed, and the callback is added to the queue, i.e., concurrentQueues), React schedules the queue to be processed, and then 2 gets printed.
However, all of this occurs within a single macrotask, which is why they appear to execute almost simultaneously.

[ltlylfun]

我觉得应该是 React 的useState 为了优化是异步批处理的。

1. React 不会立即执行这个函数
2. 它会延迟到调度更新时才执行

也就是说，console.log(2) 不一定在你 setData 之后马上发生

[lovetingyuan]

因为打印了 1 3 2，所以2不是在setData之后立即执行，但是从2的执行时间上看，这个时间几乎是立即在3之后执行的，比微任务都要快的多，我不知道js中还有什么调度机制比微任务还要快