Rendering and Reconciliation

React assumes different element types produce different trees, and that keys identify stable children. Those bets replace an O(n^3) comparison with one O(n) pass, at the cost of never reusing a subtree that moved to a new parent.

React stores hook state on the fiber node representing that component instance, as a chain of hook records matched by call order. Every rendered position has its own fiber, so two instances of the same component keep entirely separate state.

Every key is new, so no previous child matches: React deletes every existing fiber and mounts the whole list fresh on each render. Index keys at least pair positionally and reuse most fibers, so they are strictly cheaper.

React compares the next state with the current one using Object.is. Because the values match, it bails out and skips re-rendering the subtree — though it may still run this component's function once before bailing out, so never rely on that render not happening.

On the way down, React runs the component and reconciles the elements it returns into child nodes. On the way up, it finishes each node — for host elements it creates the detached DOM instance and appends its finished children — then moves to the sibling or the parent.

Each flushSync forces a full synchronous render and DOM commit inside the pointermove handler, dozens of times a second, blocking the main thread and defeating batching. Remove it and either let React batch normally or drive the moving element imperatively through a ref.

React commits the DOM, the browser paints the un-positioned tooltip, and only then does the useEffect callback move it, so one bad frame is visible. A layout effect runs inside the commit before paint, so the user only ever sees the corrected position.

Because an effect cannot run in the middle of a render. A component mounting during a render seeds its copy from the store as it is at that moment, while already-mounted components still hold whatever their subscription last delivered — so one commit contains two versions.

React remembers the snapshot each component rendered with, then re-reads it before committing and compares with Object.is. If any value moved, React throws that render away and re-renders synchronously — which only works if the snapshot value is stable between calls.

Priority is relative, so marking everything low-priority prioritises nothing. Each urgent keystroke preempts the in-flight low-priority render, which restarts from scratch, repeating work and delaying the commit until typing pauses. Mark only the expensive downstream update.

Transitions change priority, not cost. React can only yield between units of work, so one component with a very slow render still blocks a frame; and updates can escape the transition — scheduled outside its callback, or forced synchronous — leaving the whole render urgent again.

React skips a child when its props object is referentially identical to the previous render, no update is pending on it, and no context it reads has changed. Inline JSX builds a new props object every render, so this rarely fires.

Updating your own state during render makes React re-run that component immediately without committing; unguarded, it loops until React aborts with "Too many re-renders". Updating a different component's state during render is never valid and React warns, because that component already rendered in this pass.

React does not run the updater at call time; it stores it and runs it while processing the update queue during render, possibly more than once. Anything impure inside — a side effect, or mutating the previous state — fires unpredictably or corrupts the replay.

Render work is pure and in memory, so stopping or discarding it is free. Commit mutates the real DOM, so yielding partway would let the browser paint a mixture of two states and expose a half-updated tree to refs, effects and other scripts.

React can only yield between units of work, and one component's render call is a single indivisible unit. A transition lets React interrupt the tree walk, not a function already running, so a 150 ms component body still blocks the frame.

A bitmask records a whole set of pending priorities at once, so React can render a chosen subset in one pass, keep the rest marked as still pending, and tell otherwise-similar updates apart — all with cheap bitwise set operations.

React keeps the current tree, which matches what is on screen, and a work-in-progress tree it builds for the pending update; each fiber's alternate points at its counterpart in the other tree. The screen changes only when React swaps which tree is current, so unfinished work can be thrown away.

Rank each shared mutable source by whether it is read during render, how often it changes, and whether a visible disagreement would matter. Route the ones that qualify through a single tearing-safe read path, accept the rest deliberately, and budget for the interruptibility those reads give up.