Start Here

The beginner’s entry point to React Internals. The other notes in this folder are deep and checked against the React source code. This note explains the same ideas in plain English: what to read first, what each confusing word means, and which parts actually matter in an interview.

The whole thing in one paragraph

Think of a restaurant. A customer orders something (a click calls setState). The kitchen prepares the plate on the counter, where the customer can’t see it yet. The cook can stop halfway through to deal with a more urgent order, or throw the plate away and start again. This is the render phase. When the plate is ready, the waiter serves it in one go. The customer never gets half a plate. This is the commit phase. After serving, the staff do the follow-up chores: wiping the table, updating the bill. These are the effects.

In real terms: your components return elements → React compares them with what it rendered last time (reconciliation) → it records that work on a tree of objects called fibers, using a loop it can pause → it applies all the DOM changes at once (commit) → the browser paints → useEffect runs. Every other topic in this folder is a detail of one step in that sentence.

Legend

Reading order

Read these in order. Each note builds on the ones before it.

1. Render and Commit: the big picture. Read the whole note.
   • Read for: what “rendering” really means, the phases, why render must be pure, what the “virtual DOM” actually is.
2. Reconciliation: how React decides what changed. Read the whole note.
   • Read for: the type rule, keys, why state is tied to position, why you never define components inside components.
3. React Fiber: the data structure everything runs on.
   • Read: the Interview Q&A, “The problem”, “The tree is a linked list”, “Double buffering”.
   • Skim: “What a fiber holds” (the constructor field by field). You only need to know that a fiber stores type, props, state, and links to parent/child/sibling.
4. Hooks Under the Hood: where state lives and why the Rules of Hooks exist.
   • Read: the Interview Q&A, “The hook list”, “Why conditional hooks break, concretely”, “setState: from call to render”.
   • “Processing the queue during render” and rebasing: read once, don’t memorize.
5. Commit Phase and Effects: when the DOM changes and when effects run.
   • Effect ordering (child before parent, cleanups before setups), and useLayoutEffect vs useEffect.
   • The names of the sub-phases (before mutation → mutation → layout).
6. The Work Loop: how React walks the tree.
   • The “Bailouts” section: why a child re-renders when its parent does, and how memo and children stop that.
   • The beginWork/completeWork code paths: these are function names, not concepts.
7. Scheduler, Lanes and Batching: priorities and batching.
   • Batching (multiple setState calls → one render).
   • Lanes as priorities, and the fact that only transitions are interruptible.
   • The min-heap, the 5ms slices, MessageChannel, starvation timeouts: scheduler engineering trivia.
8. Child Reconciliation Algorithm: how lists are diffed.
   • Why index keys break things (the Interview Q&A covers it).
   • The lastPlacedIndex walkthroughs and the Vue LIS comparison: only useful if you’re asked to implement a diff.
9. A State Update, End to End: one click traced through React. Read this last, as a review that ties everything together. Don’t memorize the ~30 function names (); follow the story.

If you only have one evening: read notes 1, 2, 4 and 5, plus the Bailouts section of note 6, then the Top interview questions below.

Plain-English glossary

Each term has a short explanation, a label, and a link to the note that goes deeper.

The pipeline (Render and Commit)

• Element: the plain object JSX turns into, e.g. { type: 'button', props: {...} }. It’s a description of what you want on screen, like a shopping list. It’s cheap, and a new one is created on every render, then thrown away.
• Component: your function. React calls it, and it returns elements.
• Render (phase): React calling your components to find out what the UI should look like. It does not touch the DOM. “Re-render” means “your function ran again”, not “the screen was rebuilt”.
• Commit (phase): React applying the changes it found to the real DOM, all in one go.
• Paint: the browser drawing pixels. This is the browser’s job, not React’s, and it happens after the commit.
• Trigger: what starts an update. Either the first root.render(), or a state update (setState, a reducer dispatch, etc.).
• Pure render: your component must give the same output for the same input and must not change anything outside itself. React may call it twice (Strict Mode), several times (interrupted transitions) or not at all (bailouts).
• Virtual DOM: a marketing term. Precisely: React compares new elements against its previous fiber tree. It never reads the real DOM to find out what changed. If an interviewer says “virtual DOM”, it’s fine to say this.

Reconciliation (Reconciliation)

• Reconciliation: the “spot the difference” step. React compares what your component returned now with what it returned last time, and decides what to keep, update, create or delete. It happens during render. The actual DOM changes happen later, in the commit.
• Type rule: if an element’s type changes (<div> → <span>, or ComponentA → ComponentB), React throws away the whole old subtree, including its state, and builds a new one. It doesn’t look inside.
• Key: a name tag for list items, so React can recognize “the same item” even if it moved. Without keys, React matches items by their position in the list.
• State is tied to position: React remembers state by where a component sits in the tree (plus its type and key), not by the variable name. Same type at the same spot keeps its state.
• Remount: destroy and re-create a component, losing its state and DOM. Changing the key forces one, which is a common trick to reset a form.
• O(n) heuristic: a perfect tree diff costs O(n³). React gets O(n) by assuming that “different type means a different tree” and by trusting keys. Say this in one sentence and move on.

Fiber (React Fiber)

• Fiber: a plain JS object, one for each mounted component or DOM element, that stores everything React knows about it: type, props, state, hooks, pending work, and links to its relatives. Unlike elements, fibers persist between renders. Think of it as the component’s “file” in React’s records.
• Why Fiber exists: the old “stack reconciler” used recursion, and you can’t pause recursion halfway through. Fiber turns the tree into linked objects that a loop walks one at a time, so React can pause, resume, prioritize, or throw away work.
• Stack reconciler: the pre-React-16 engine. You only need to know it as “the one that couldn’t pause”.
• Unit of work: processing one fiber. React can stop between any two units of work.
• child / sibling / return: the three pointers on each fiber: first child, next sibling, and parent (“return” because that’s where you return to when you’re done). Together they let a loop walk the tree without recursion.
• current vs workInProgress: current is the tree on screen right now. workInProgress is the draft being built during render. The user only ever sees current.
• alternate: the pointer connecting a fiber’s “current” version with its “draft” version.
• Double buffering: borrowed from graphics. You draw the next frame off-screen, then swap. The commit makes the draft the new current by switching a single pointer, and the old tree is reused as scratch space for the next render.
• stateNode: the fiber field that points to the real DOM node (or class instance). It’s a field name, not a concept.
• flags / effect tags: bits on a fiber that say things like “insert me” or “update me”, so the commit knows what to do. It’s enough to know that render marks the work and commit performs it.

The work loop (The Work Loop)

• Work loop: a while loop that processes one fiber at a time. It goes down to the children, then across to the siblings, then back up to the parent.
• performUnitOfWork / beginWork / completeWork: the internal functions for “process this fiber on the way down” and “finish it on the way up”. These are just names; describe the down-then-up walk instead.
• Bailout: React skipping a component because it can tell nothing changed: the props object is the same, there’s no state update, and no context change. If nothing below it changed either, React skips the whole subtree.
• Why children re-render with the “same” props: a parent’s render creates new elements, which means a new props object, and React compares props by reference (!==). memo switches this to a shallow comparison of each prop. Passing elements in as children keeps the same object, so the child is skipped without needing memo.
• childLanes: a “something below me has pending work” flag on each fiber. It’s how React knows it can skip a whole subtree.

Commit and effects (Commit Phase and Effects)

• Commit is synchronous: once React starts changing the DOM, it doesn’t stop, so you never see a half-updated UI. All the pausable work happens before the first DOM write.
• Sub-phases: before mutation (read the DOM, e.g. getSnapshotBeforeUpdate) → mutation (change the DOM) → swap (current = the new tree) → layout (attach refs, run useLayoutEffect).
• useLayoutEffect: runs after the DOM changes but before the browser paints. Use it to measure the DOM and fix up layout without a visible flicker. It blocks painting, so keep it short.
• useEffect: runs after paint, so it doesn’t delay what the user sees. It’s the default choice for data fetching, subscriptions and logging.
• Effect order: children’s effects run before their parent’s. For each kind of effect, all cleanups run before any new setup.
• Refs: ref.current is set during the layout sub-phase, which is why a ref is available inside useLayoutEffect and useEffect but not during render.

Scheduling (Scheduler, Lanes and Batching)

• Batching: setState doesn’t render right away. It queues an update. All the updates made in the same event (or the same tick) are rendered together once. Since React 18 this happens everywhere: in promises, timeouts and native event listeners too (“automatic batching”).
• Transition (startTransition, useTransition): marks an update as “not urgent”. React renders it in the interruptible mode and will drop it if something urgent, like typing, comes in.
• Priority / lane: every update gets a priority. A lane is React’s name for a priority, stored as one bit in a number so React can group and compare priorities cheaply. Say “lanes are how React represents update priority”, and that’s enough.
• Not everything is concurrent: clicks, typing and normal updates render synchronously, without stopping. Only transitions, useDeferredValue, and a few internal cases use the interruptible loop. People get this wrong in interviews all the time.
• Time slicing / yielding: in the interruptible mode, React works for a few milliseconds, then hands control back to the browser so it can handle input and paint, then continues.
• Interruption: if an urgent update arrives in the middle of a transition render, React throws the draft away, handles the urgent update, and redoes the transition later. This is why render must be pure.
• Starvation protection: transitions that keep being interrupted eventually get forced through synchronously. It’s a safety net and doesn’t affect how you write code.
• Scheduler package internals (min-heap, 5ms slice, MessageChannel): engineering details of the task queue.

Hooks (Hooks Under the Hood)

• Where state lives: on the component’s fiber, not in the function. Your function forgets everything when it returns. React hands the state back on every call.
• Hook list: each fiber keeps its hooks in a linked list, in call order: the 1st useState, the 2nd useEffect, and so on. React matches hook calls to stored data by position, not by name.
• Why the Rules of Hooks exist: because of the point above. If an if skips one hook call, every later hook reads the wrong slot, which gives you swapped state or the error “Rendered more hooks than during the previous render”.
• setState with a value vs an updater: setCount(count + 1) three times adds 1, because all three use the same stale count. setCount(c => c + 1) three times adds 3, because each one gets the previous result.
• setState is stable: it’s created once on mount and bound to the fiber, so it never changes. That’s why it’s safe to leave out of dependency arrays.
• Update queue: each state hook has a queue of pending updates, which React processes during the next render.
• Eager bailout: if you set the same value (Object.is) and nothing else is pending, React often doesn’t schedule a render at all.
• Dispatcher: the internal object that makes useState mean “mount” on the first render and “update” after that. It’s also why calling a hook outside a component throws an error. It’s a mechanism, not something you’ll be asked about.
• memoizedState: the fiber field that holds the first hook. It’s just a field name.
• Rebasing: how low-priority updates are replayed after high-priority ones. It’s correct, but too deep for almost any interview.

List diffing (Child Reconciliation Algorithm)

• Index keys are dangerous: if you insert an item at the front, the old item 0’s state and DOM node get reused for the new item 0. Inputs, focus and local state end up on the wrong row.
• Key Map: when items move, React puts the old children in a Map by key and looks up each new child in it.
• lastPlacedIndex: the trick React uses to decide which items to move. Moving the last item to the front costs n−1 moves. It’s only useful if you’re asked to implement a diff.
• LIS (Vue): Vue computes the minimum number of moves and React doesn’t. It’s a fun fact, not interview material.

Commonly confused pairs

Top interview questions

Short answers you can say out loud. Each one links to the note that goes deeper.

Self-check

Try to explain each of these out loud, without looking. If you get stuck, reread the linked note.

• Walk through what happens from a button click to the pixels changing. (A State Update, End to End)
• What’s the difference between an element and a fiber? (React Fiber)
• Why is <Child /> defined inside Parent a bug? (Reconciliation)
• Where does useState actually keep its value? (Hooks Under the Hood)
• In what order do parent and child effects and cleanups run? (Commit Phase and Effects)
• Give two ways to stop a child from re-rendering when its parent does. (The Work Loop)
• Which updates can be interrupted, and why can the commit never be? (Scheduler, Lanes and Batching)
• What goes wrong with index keys when you prepend an item? (Child Reconciliation Algorithm)