React Fiber Architecture Interview Questions

The stack reconciler problem

// Conceptually, the OLD React reconciler worked like this:
function reconcile(element, domNode) {
  // Recursive — cannot be paused mid-execution
  updateDOMNode(domNode, element.props)
  const children = element.props.children
  children.forEach((child, i) => {
    reconcile(child, domNode.childNodes[i])  // recursive call
  })
}
// Problem: JavaScript call stack is synchronous and uninterruptible.
// A component tree 1000 nodes deep = 1000 recursive calls
// that hold the main thread for the entire duration.
// During this time: no input events, no animations, nothing.
// Observed symptom: Typing in an input connected to state
// caused the UI to freeze for 200-500ms on large trees.
// This is what Fiber was built to fix.

What a Fiber node actually is

// A Fiber is a plain JavaScript object. Roughly:
const fiber = {
  // Identity
  type: MyComponent,          // function or class or 'div' etc.
  key: null,
  // Input
  pendingProps: { name: 'Alice' },
  memoizedProps: { name: 'Alice' },   // props from last completed render
  memoizedState: { count: 0 },        // hooks state (linked list of hook objects)
  // Tree structure — the 3 pointers people always miss:
  return: parentFiber,        // pointer to parent (NOT called "parent")
  child: firstChildFiber,     // pointer to first child only
  sibling: nextSiblingFiber,  // pointer to next sibling
  // Effect tracking
  flags: Update | Placement,  // bitmask of what DOM work is needed
  subtreeFlags: 0,            // aggregate flags from all descendants
  // Double buffering
  alternate: workInProgressFiber,  // pointer to the other tree's version of this fiber
  // Scheduling
  lanes: SyncLane,            // what priority is pending work at
  childLanes: 0,              // aggregate lanes of all descendants
}
// The two fields most people miss:
// 1. "return" (not "parent") — React calls it "return" because it's where
//    the fiber "returns" after completing its work (like a call stack frame)
// 2. "alternate" — each fiber has exactly one alternate pointing to its
//    counterpart in the other tree (current ↔ work-in-progress)

The linked list traversal — depth-first, child-then-sibling

// For a tree like:
//     App
//    /   \
//  Nav   Main
//         |
//       Article
// React builds it as a linked list:
// App.child → Nav
// Nav.sibling → Main
// Main.child → Article
// Article.return → Main
// Main.return → App
// Nav.return → App
// React walks this with a simple work loop:
function workLoop(deadline) {
  while (nextUnitOfWork !== null) {
    // Process one fiber. Returns next unit of work.
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork)
    // KEY: check if browser needs the thread back
    if (deadline.timeRemaining() < 1) {
      break  // yield! Resume next frame.
    }
  }
  if (nextUnitOfWork !== null) {
    // Schedule ourselves to run again in the next frame
    requestIdleCallback(workLoop)
  } else {
    // All work done — safe to commit
    commitRoot()
  }
}
// React uses a custom scheduler (not actual requestIdleCallback in prod)
// but the concept is identical: process one fiber, check remaining time, yield if needed.
// This is the fundamental mechanism behind interruptible rendering.

Double buffering — current tree vs work-in-progress

// At any point in time, React holds two trees:
//
// CURRENT TREE                  WORK-IN-PROGRESS TREE
// (on screen right now)         (being built for next render)
//
//     App ←——————alternate——————→ App'
//    /   \                       /   \
//  Nav   Main                  Nav'  Main'
//         |                           |
//       Article                     Article'
//
// Each fiber points to its alternate via the .alternate field.
// React builds the work-in-progress tree by cloning and updating fibers.
// The clone is cheap — it reuses most fields, only changing what needs updating.
// When rendering is complete:
function commitRoot() {
  // Swap the trees atomically:
  root.current = workInProgressRoot
  // The old current tree becomes the new work-in-progress
  // (will be reused as the base for the next render — that's the "double" in double buffering)
}
// Why this matters:
// React can abandon an incomplete work-in-progress tree with no visible consequences.
// The current tree (on screen) is never touched until the new tree is fully ready.
// This is what makes Concurrent Mode safe: users never see half-rendered UIs.

The workLoop and yielding to the browser

// React's Scheduler package implements cooperative multitasking:
// It uses MessageChannel (not setTimeout) for near-zero-delay callbacks.
// Simplified internals:
const channel = new MessageChannel()
let scheduledCallback = null
channel.port1.onmessage = function() {
  if (scheduledCallback) {
    const frameDeadline = performance.now() + 5  // 5ms budget per frame
    scheduledCallback({ timeRemaining: () => frameDeadline - performance.now() })
    scheduledCallback = null
  }
}
function scheduleWork(callback) {
  scheduledCallback = callback
  channel.port2.postMessage(null)  // triggers port1.onmessage asynchronously
}
// React processes fibers within the 5ms budget.
// If the budget runs out, it posts another message and yields.
// The browser gets to run between messages:
// handle input events, run animations, paint — then return control to React.
// 5ms per frame at 60fps = browser gets ~11ms, React gets 5ms.
// At 120fps: browser needs ~3ms, React gets ~5ms.
// The scheduler adapts to the display refresh rate.

Lanes — the priority system

// Every update in React is assigned a lane — a bitmask representing priority.
// Lane values (simplified):
const SyncLane           = 0b0000000000000000000000000000001  // synchronous, highest priority
const InputContinuousLane = 0b0000000000000000000000000000100  // continuous input (e.g. drag)
const DefaultLane        = 0b0000000000000000000000000010000  // normal updates
const TransitionLane1    = 0b0000000000000000000001000000000  // startTransition updates
const IdleLane           = 0b0100000000000000000000000000000  // background work
// How lanes enable priority:
function handleUserTyping(e) {
  // React assigns SyncLane — must update synchronously
  setInputValue(e.target.value)
}
function handleTransition() {
  startTransition(() => {
    // React assigns TransitionLane — can be deferred
    setFilteredResults(computeExpensiveFilter(inputValue))
  })
}
// When a SyncLane update arrives while a TransitionLane render is in progress:
// React interrupts the TransitionLane work
// Processes the SyncLane update immediately (input feels instant)
// Then resumes (or restarts) the TransitionLane work
// This is why clicks feel instant during expensive renders in React 18.
// The click's SyncLane interrupts the background Transition work.
// Batching also uses lanes: React collects all updates in the same event handler,
// assigns them the same lane, and renders them together in one pass.

What "interruptible rendering" does and does NOT mean

// What it DOES mean:
// React can pause building the work-in-progress tree mid-traversal,
// yield the main thread back to the browser,
// handle higher-priority work (input events, animations),
// then resume building the work-in-progress tree.
// What it does NOT mean:
// It does NOT mean React partially updates the DOM.
// The commit phase is ALWAYS synchronous and uninterrupted.
// The user never sees a half-rendered tree.
// Correct mental model:
// [render phase — interruptible]  →  [commit phase — always atomic]
//   build work-in-progress tree       apply all mutations at once
// Consequence: component render functions (the body of your component)
// may be called MORE THAN ONCE for a single visible update.
// React might start rendering a component, yield, then restart from scratch.
// This is why render functions must be pure — side effects in them are dangerous.
// ✗ Wrong: side effect in render
function Component() {
  analytics.track('render')  // will fire multiple times per visible update!
  return <div />
}
// ✓ Correct: side effect in useEffect
function Component() {
  useEffect(() => { analytics.track('render') }, [])  // fires once after commit
  return <div />
}