<p><strong>NOTE: I accidentally exited out of the browser tab while writing this post 2 times (so this is my third attempt). As you can imagine, I'm feeling extremely frustrated right now lol so I'm posting this draft for now. If you would like me to resume my explanation or have any questions, please comment below and I'll try to get back to you asap!</strong></p>
<p><strong>Feel free to explore the results and the case studies below for yourself in <a href="https://codesandbox.io/p/sandbox/useeffect-timing-ii-gyrl2l?file=%2Fsrc%2Findex.js%3A30%2C34">CodeSandbox</a>.</strong></p>
<h2>Accepted Solution:</h2>
<pre><code>1 // render
3 // Promise callback
4 // setTimeout callback
2 // useEffect callback
</code></pre>
<h2>Explanation</h2>
<h3>Why does the blocking <code>while</code> loop force the <code>useEffect</code> callback to run at a later time?</h3>
<ul>
<li>The <code>while</code> loop runs for 50ms, which is a significant amount of time in terms of JavaScript execution. This loop blocks the main thread, preventing React from immediately committing the render and running effects.</li>
<li>React's effect scheduling is tied to its reconciliation and commit phases. When a component renders, React first performs reconciliation to determine what changes need to be made to the DOM. Then, in the commit phase, it applies these changes and schedules effects to run.</li>
<li>The long-running while loop delays this entire process. By the time React is able to proceed with its commit phase and effect scheduling, the Promise microtask and the setTimeout macrotask have already been queued.</li>
</ul>
<p>The key takeaway is that the long-running synchronous code (the while loop) pushes the React commit phase and effect execution later in the event loop, allowing other queued tasks to execute first.</p>
<h3>Without the blocking <code>while</code> loop</h3>
<pre><code>function App() {
  const [state] = useState(0)
  console.log(1)
  
  useEffect(() =&gt; {
    console.log(2)
  }, [state])

  Promise.resolve().then(() =&gt; console.log(3))

  setTimeout(() =&gt; console.log(4), 0)

  return null
}
</code></pre>
<p><strong>Console Output:</strong></p>
<pre><code>1 // render
2 // useEffect callback
3 // Promise callback
4 // setTimeout callback
</code></pre>
<p><a href="https://codesandbox.io/p/sandbox/useeffect-timing-ii-gyrl2l?file=%2Fsrc%2FAppWithoutBlockingLoop.js%3A20%2C18">Test it yourself in CodeSandbox</a></p>
<h3>Using useLayoutEffect instead of useEffect</h3>
<pre><code>function App() {
  const [state] = useState(0);
  console.log(1);

  const start = Date.now();
  while (Date.now() - start &lt; 50) {
    window.timestamp = Date.now();
  }

  useLayoutEffect(() =&gt; {
    console.log(2);
  }, [state]);

  Promise.resolve().then(() =&gt; console.log(3));

  setTimeout(() =&gt; console.log(4), 0);

  return null;
}
</code></pre>
<p><strong>Console Output:</strong></p>
<pre><code>1 // render
2 // useEffect callback
3 // Promise callback
4 // setTimeout callback
</code></pre>
<p><a href="https://codesandbox.io/p/sandbox/useeffect-timing-ii-gyrl2l?file=%2Fsrc%2FAppWithLayoutEffect.js%3A7%2C1-10%2C4">Test it yourself in CodeSandbox</a></p>
<h2>Key Takeaways</h2>
<ul>
<li>The long-running synchronous code (the while loop) pushes the React commit phase and effect execution later in the event loop, allowing other queued tasks to execute first.</li>
<li>In React 18, useEffect fires synchronously when it's the result of a discrete input</li>
</ul>

Detailed Explanation: Why the blocking loop delays useEffect (DRAFT)

What does the code snippet to the right output by console.log?…