Have you ever written a line of React code, looked at the output in your browser, and thought: "Wait... why did it do that?"
Here is the classic code snippet that every single React developer writes at least once:
You click the button. The button text updates on the screen from 0 to 1. But in your browser console, it logs:
At first, you think it is just a tiny delay. So you click it again. The button updates to 2, but the console logs 1. It is always one step behind.
When I first ran into this years ago, someone on a forum told me: "Oh, setState is asynchronous." And for months, I accepted that answer. But that answer is not the whole truth. In fact, thinking of state as a "variable that updates asynchronously" is the exact mental model that causes hundreds of bugs in production apps.
Today, we are going to look under the hood. No fluff. No textbook definitions. We are going to look at the real data structures, the Fiber tree, why hook rules exist, and how React actually turns your JavaScript into pixels on a screen.
When most of us learn React, our brain builds a very simple model of how it works: You call setCount(1) React goes into your HTML It changes Count: 0 to Count: 1 Done.
If this were how React worked, React would be terrible. Directly searching and mutating the browser DOM on every state update is slow and expensive. The browser has to recalculate styles, recalculate layout geometry (reflow), and repaint pixels.
React does not update the DOM when you call setState. It schedules a calculation to run in the future.
Let's break down the three distinct phases that happen every single time your component updates.
Think of React like a high-end restaurant kitchen. Trigger Phase: The customer places an order. Render Phase: The chef cooks the food and plates it on the counter (in private, inside the kitchen). Commit Phase: The waiter takes the dish and sets it on the customer's table.
If the customer changes their mind halfway through cooking, the chef can throw away the half-cooked plate without the customer ever seeing it. But once the plate hits the table, that is the commit.
When you call setCount(count + 1), your component function does not immediately run again.
Instead, React creates an Update Object and puts it into an update queue attached to that component's internal representation. React marks this component as "dirty" and schedules work with the React Scheduler.
If you click a button three times rapidly, or update three different state variables inside the same event handler, React batches them together. It does not run the kitchen three times for three breadsticks. It collects the whole order first. The Render Phase (Pure JavaScript)
When developers hear "render", they think of the screen drawing pixels. In React, rendering just means calling your component function.
Under the hood, the compiler (Babel or Vite) turns that JSX into a regular JavaScript function call:
And React.createElement() simply returns a plain, lightweight JavaScript object: