React Fiber Reconciliation & Hook Internals

React has transformed from a straightforward virtual DOM rendering library into a sophisticated concurrent runtime engine. At the heart of modern React (v16 through v19) lies the Fiber Reconciler—a ground-up rewrite of React's core reconciliation algorithm that replaced the synchronous, recursive stack reconciler with an asynchronous, interruptible virtual execution stack.

Understanding Fiber internals is not an academic exercise; it is the prerequisite for diagnosing complex rendering performance bottlenecks, mastering concurrent features like useTransition and useDeferredValue, understanding how hooks maintain state across renders, and avoiding dangerous stale closure bugs.

This guide provides an exhaustive, university-grade architectural analysis of React Fiber and hook internals. We dissect the Fiber node data structure, trace the double-buffering reconciliation algorithm, analyze the 31-bit Lanes concurrency priority bitmask, inspect the internal hook linked-list state machine, diagnose classic rendering pathologies, and walk through four comprehensive quantitative checkpoint problems.

1. The Architectural Evolution of React Reconciliation#

To understand Fiber, one must understand why the legacy reconciler failed.

The Stack Reconciler Limitations#

Prior to React 16, React used the Stack Reconciler. Reconciliation was implemented as a synchronous recursive walk over the Virtual DOM tree:

• When a component called setState(), React recursively traversed the entire component tree, comparing current elements with newly returned elements.
• This recursive walk could not be paused, interrupted, or yielded.
• On large, complex DOM trees with thousands of nodes, a reconciliation pass could take 100 to 200 milliseconds of uninterrupted JavaScript execution on the browser's single main thread.

Because the browser must handle user input events (clicks, typing), execute layout recalculations, and repaint the screen within a strict 16.67-millisecond frame budget (to maintain 60 frames per second), any JavaScript execution exceeding 16.67 ms causes frame drops, UI freezing, and jank.

+-------------------------------------------------------------------------------------------------+
|                                 FRAME BUDGET EXECUTION TIMELINE                                 |
|                                                                                                 |
|   Target Frame Duration: 16.67 ms (60 FPS)                                                      |
|   +-----------------------------------------------------------------------------------------+   |
|   | Input Events | JS Execution | Style / Layout | Paint / Composite | Idle / RAF           |   |
|   | (~2 ms)      | (<= 8-10 ms) | (~3 ms)        | (~2 ms)           | (Yield to Browser)   |   |
|   +-----------------------------------------------------------------------------------------+   |
|                                                                                                 |
|   Stack Reconciler (Monolithic Block: 150 ms) -> 9 Consecutive Frames Dropped! UI Freezes!      |
|   [========================================================================================]    |
|                                                                                                 |
|   Fiber Reconciler (Interruptible Time-Sliced Chunks: 5 ms each)                                |
|   [Chunk 1: 5ms] -> [Yield/Paint] -> [Chunk 2: 5ms] -> [Handle User Click] -> [Chunk 3: 5ms]   |
+-------------------------------------------------------------------------------------------------+

The Fiber Reconciler: An Incremental Virtual Stack#

The Fiber architecture solves this fundamental problem by converting the recursive call stack into a linked list of virtual stack frames (called Fiber nodes).

Because each Fiber node maintains explicit pointers to its child, sibling, and parent, React can pause tree traversal at any node, save its execution position in memory, yield control back to the browser to process high-priority user input or run screen repaints, and later resume traversal exactly where it left off.

2. The Fiber Node Data Structure & Double Buffering#

A Fiber represents an atomic unit of work and corresponds directly to a React component instance, a DOM element, or a context provider.

+-------------------------------------------------------------------------------------------------+
|                                     FIBER NODE DATA STRUCTURE                                   |
|                                                                                                 |
|   FiberNode {                                                                                   |
|     // Tag & Identity                                                                           |
|     tag: WorkTag;              // Identifies type (FunctionComponent, HostComponent, etc.)     |
|     key: null | string;        // Reconciliation reconciliation key                             |
|     type: any;                 // The component function/class or DOM tag ('div', 'span')       |
|     stateNode: any;            // Reference to actual DOM node or class instance                |
|                                                                                                 |
|     // Singly-Linked Tree Structure                                                             |
|     return: Fiber | null;      // Pointer to Parent Fiber                                       |
|     child: Fiber | null;       // Pointer to First Child Fiber                                  |
|     sibling: Fiber | null;     // Pointer to Next Sibling Fiber                                 |
|     index: number;             // Sibling index position                                        |
|                                                                                                 |
|     // State & Props                                                                            |
|     memoizedProps: any;        // Props used to render the last output                          |
|     pendingProps: any;         // Props passed in for the upcoming render                       |
|     memoizedState: any;        // Internal Hook Linked List or Class State                      |
|                                                                                                 |
|     // Concurrency & Priority                                                                   |
|     lanes: Lanes;              // 31-bit Bitmask representing priority of work                  |
|     childLanes: Lanes;         // Subtree priority bitmask                                      |
|                                                                                                 |
|     // Double Buffering Twin Pointer                                                            |
|     alternate: Fiber | null;   // Points to the corresponding node in the other tree            |
|   }                                                                                             |
+-------------------------------------------------------------------------------------------------+

The Double Buffering Pattern#

To ensure that half-computed virtual DOM trees are never rendered to the screen (which would cause flickering and visual inconsistencies), React employs graphics-style Double Buffering:

React maintains two complete Fiber trees in memory simultaneously:

1. The `current` Tree: Represents the state of the UI currently rendered and visible on the physical screen. React never mutates nodes on the current tree during reconciliation.
2. The `workInProgress` Tree: The secondary tree constructed and mutated in memory during the background rendering phase.

+-------------------------------------------------------------------------------------------------+
|                                 DOUBLE BUFFERING TREE TOPOLOGY                                  |
|                                                                                                 |
|   CURRENT TREE (Screen Visible)                WORK IN PROGRESS TREE (Background Computation)   |
|                                                                                                 |
|       [RootFiber] <====================================> [RootFiber WIP]                        |
|       (current)            alternate pointer             (workInProgress)                       |
|           |                                                      |                              |
|           v                                                      v                              |
|       [AppFiber]  <====================================> [AppFiber WIP]                         |
|         /    \                                                 /    \                           |
|        v      v                                               v      v                          |
|    [Header]  [Sidebar]                                    [Header]  [Sidebar]                   |
|                                                                                                 |
|   ===========================================================================================   |
|   COMMIT PHASE: When workInProgress tree completes, Root.current pointer switches instantly!   |
|                 Root.current = workInProgress;                                                  |
+-------------------------------------------------------------------------------------------------+

Every Fiber node points to its twin via the alternate property:

currentFiber.alternate === workInProgressFiber and workInProgressFiber.alternate === currentFiber.

When reconciliation completes, React switches a single root pointer:

fiberRoot.current = workInProgressTree.

The workInProgress tree instantly becomes the current tree in an atomic O(1) operation. In the subsequent render, the old current tree is recycled as the new workInProgress buffer, avoiding garbage collection thrashing.

The Two-Phase Reconciliation Pipeline#

React divides execution into two distinct phases with entirely different performance characteristics:

+-------------------------------------------------------------------------------------------------+
|                                 THE TWO-PHASE EXECUTION PIPELINE                                |
|                                                                                                 |
|   PHASE 1: RENDER / RECONCILIATION PHASE (Asynchronous & Interruptible)                         |
|   - Traverses the workInProgress Fiber tree.                                                    |
|   - Invokes component functions (renders).                                                      |
|   - Calculates virtual diffs and flags side-effects (Placement, Update, Deletion).              |
|   - Can be paused, yielded to browser frame budget, or completely aborted if higher-priority    |
|     input arrives.                                                                              |
|   - ZERO DOM MUTATIONS OCCUR IN THIS PHASE.                                                     |
|                                 |                                                               |
|                                 v                                                               |
|   PHASE 2: COMMIT PHASE (Synchronous & Uninterruptible)                                         |
|   - Flushes accumulated side-effects to the real host DOM in a single atomic burst.             |
|   - Sub-phase 2a (Before Mutation): Reads layout (getSnapshotBeforeUpdate).                     |
|   - Sub-phase 2b (Mutation): Inserts, updates, and deletes physical DOM nodes.                  |
|   - Sub-phase 2c (Layout): Executes useLayoutEffect synchronously before browser paint.         |
|   - Swaps Root.current pointer to workInProgress tree.                                          |
|   - Sub-phase 2d (Passive): Schedules useEffect asynchronously AFTER the browser paints screen. |
+-------------------------------------------------------------------------------------------------+

3. The React Scheduler & Lanes Concurrency Model#

In React 18+, React replaced the coarse priority levels of earlier schedulers with the Lanes Priority Model.

The 31-bit Lanes Bitmask#

A Lane is represented as a 31-bit integer bitmask (since JavaScript bitwise operations operate on 32-bit signed integers). Each bit in the mask represents an independent lane of work, with lower bit positions representing higher execution priority:

Bit Position:
30 29 28 ...  16 15 ...  4  3  2  1  0
 0  0  0 ...   0  0 ...  0  0  0  1  0  ---> InputContinuousLane (User drag/scroll)
 0  0  0 ...   0  0 ...  0  0  0  0  1  ---> SyncLane (User click / typing)

The foundational Lanes categories include:

• `SyncLane` (Bit 0: `0b00000001`): Discrete synchronous user interactions (button clicks, form inputs). Must execute immediately.
• `InputContinuousLane` (Bit 1-2): Continuous user interactions (hovering, mouse dragging, scrolling).
• `DefaultLane` (Bit 3-4): Standard asynchronous updates (network data fetch completions).
• `TransitionLane` (Bits 5-20): Low-priority transitions created via startTransition or useTransition. Can be interrupted by incoming SyncLane work.
• `IdleLane` (Bits 29-30): Background maintenance work (pre-fetching offscreen content).

Bitwise Operations for Priority Isolation#

React leverages high-speed bitwise arithmetic to manipulate priority sets in single CPU instructions:

1. Isolating the Highest Priority Lane:

To find the lowest non-zero bit (the highest priority task) in a bitmask lanes:

```javascript

function getHighestPriorityLane(lanes) {

return lanes & -lanes; // Two's complement bitwise trick!

}

```

1. Merging Lanes:

```javascript

combinedLanes = currentLanes | newUpdateLane;

```

1. Checking if Lane is Included:

```javascript

const hasSyncWork = (lanes & SyncLane) !== 0;

```

When a user types into an input field, React assigns the update to SyncLane. If a background data table update was currently rendering on TransitionLane, React immediately halts work on the transition, drops the uncommitted workInProgress tree, processes the SyncLane update to paint the user's keystroke with zero latency, and restarts the transition update afterwards.

4. Hook Internals & The Hook Linked List#

In functional components, React hooks (such as useState, useEffect, useRef, and useMemo) are not stored in global variables or component closures. Instead, they are stored as a singly-linked list of Hook nodes attached to the Fiber's `memoizedState` property.

+-------------------------------------------------------------------------------------------------+
|                                 HOOK LINKED LIST STATE MACHINE                                  |
|                                                                                                 |
|   Fiber.memoizedState ---> [Hook 1: useState]                                                   |
|                            - memoizedState: 42 (Current Value)                                  |
|                            - queue: { pending: UpdateNode } (Update Ring Buffer)                |
|                            - next: ------------------------------------+                        |
|                                                                        |                        |
|                            +-------------------------------------------+                        |
|                            v                                                                    |
|                            [Hook 2: useRef]                                                     |
|                            - memoizedState: { current: DOMElement }                             |
|                            - next: ------------------------------------+                        |
|                                                                        |                        |
|                            +-------------------------------------------+                        |
|                            v                                                                    |
|                            [Hook 3: useEffect]                                                  |
|                            - memoizedState: { create: fn, deps: [42], tag: HookPassive }       |
|                            - next: null (End of list)                                           |
+-------------------------------------------------------------------------------------------------+

The Hook Node Anatomy#

type Hook = {
  memoizedState: any;       // The cached state value or effect record
  baseState: any;           // The baseline state used for priority updates
  baseQueue: Update | null; // Queued updates that could not be processed due to priority
  queue: UpdateQueue | null;// Circular ring buffer of newly enqueued updates
  next: Hook | null;        // Pointer to the next hook in the component
};

Why the "Rules of Hooks" Exist#

The official React documentation mandates two strict rules:

1. Only call Hooks at the top level. Do not call Hooks inside loops, conditions, or nested functions.
2. Only call Hooks from React function components.

The Low-Level Architectural Reason:

React tracks hooks strictly by pointer index traversal order:

• On the initial render (mount), React allocates a new Hook node for each hook declaration and links them sequentially: hook1.next = hook2; hook2.next = hook3;.
• On subsequent re-renders (update), React resets an internal pointer workInProgressHook = currentFiber.memoizedState.
• Every time a hook is called (e.g., useState()), React reads the current node from workInProgressHook, processes its state, and advances the pointer: workInProgressHook = workInProgressHook.next.

If a hook is wrapped inside an if (condition) block that evaluates to false on a re-render:

• The hook is skipped.
• The pointer index shifts out of alignment!
• A useRef node is mistakenly read by React as if it were a useState node, corrupting memory, breaking dependency arrays, and triggering runtime crashes.

The Stale Closure Pathology in Hooks#

A stale closure occurs when a hook callback (such as an effect or timer callback) captures state or props from an earlier render cycle due to lexical scoping:

// The Classic Stale Closure Bug
function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const timer = setInterval(() => {
      // FAILS: 'count' is frozen at 0 inside the effect's closure!
      setCount(count + 1); 
    }, 1000);
    return () => clearInterval(timer);
  }, []); // Empty dependency array captures render 0 forever!

  return <h1>{count}</h1>;
}

CPython / V8 JavaScript Root Cause: The arrow function passed to setInterval was evaluated during mount when count = 0. Because the dependency array [] tells React never to recreate the effect, the closure forever references the lexical environment of render 0. Every second, it evaluates setCount(0 + 1), setting state to 1 repeatedly.

Remediation: Functional State Updates:

// Fixed: Functional update passes the fresh pending state directly from the update queue
setCount(prevCount => prevCount + 1);

5. Anti-Patterns & Common Pitfalls#

The "Effects as Data Transformers" Anti-Pattern#

A widespread anti-pattern in React codebases is utilizing useEffect to synchronize or compute derived state:

// ANTI-PATTERN: Unnecessary cascading render cycles
function UserProfile({ firstName, lastName }) {
  const [fullName, setFullName] = useState("");

  useEffect(() => {
    // Triggers a second re-render cycle after every prop change!
    setFullName(`{firstName} {lastName}`);
  }, [firstName, lastName]);

  return <h1>{fullName}</h1>;
}

Remediation: Compute derived values directly in the render body. If the calculation is computationally expensive, memoize with useMemo:

// Idiomatic: Computed during render; zero extra render cycles
const fullName = `{firstName} {lastName}`;

Mutating State In-Place (Violating Object Identity)#

React uses Object.is to compare current state with newly queued state in useState:

// ANTI-PATTERN: In-place array mutation
const [items, setItems] = useState([1, 2, 3]);

function addItem() {
  items.push(4); // Mutates existing array in-place!
  setItems(items); // Object.is(items, items) === true! REACT BAILS OUT AND NEVER RE-RENDERS!
}

Remediation: Always return a new object/array reference: setItems([...items, 4]).

6. Checkpoint Practice Problems#

The following four multi-part quantitative problems evaluate Fiber tree alternate pointer manipulation, Lanes priority bitmask mathematics, hook linked-list state machine resolution, and concurrent frame budget scheduling. Complete step-by-step solutions follow each problem prompt.

Problem 1: Fiber Tree Traversal & WorkInProgress Alternate Pointer Mechanics#

Context:

A frontend engineer is inspecting the Fiber reconciliation pass of a three-level component hierarchy:

          [App (Root)]
            /      \
      [Navbar]   [Dashboard]
                   /     \
             [Chart]   [Metrics]

The application is mounted on screen, with all 5 nodes existing in the current Fiber tree. A user interaction triggers a state update in [Dashboard].

Questions:

1. Trace the exact depth-first search (DFS) traversal order of the workInProgress tree during the render phase (using child, sibling, and return pointers) starting from Root.
2. For each node visited, specify whether React clones the existing Fiber via createWorkInProgress() or creates a brand new Fiber node.
3. If Navbar does not consume any changed props or context, how does React's bailout mechanism (checkScheduledUpdateOrContext) bypass rendering Navbar's subtree?
4. When workInProgress completes and the commit phase executes, show the exact pointer swap that transitions the workInProgress tree to become the current tree.

Solution:

Step 1: DFS Traversal Sequence via Child-Sibling-Return Pointers

The React reconciliation loop (workLoopSync / workLoopConcurrent) executes DFS traversal using beginWork() going down and completeWork() going up:

1. beginWork(Root): Inspects root, moves to first child -> Root.child (Navbar).
2. beginWork(Navbar): Identifies no pending updates for Navbar. Returns Navbar.sibling -> Dashboard.
3. beginWork(Dashboard): Identifies pending state update! Invokes Dashboard() function component. Returns first child -> Dashboard.child (Chart).
4. beginWork(Chart): Executes Chart(). Has no children (Chart.child === null).
5. completeWork(Chart): Prepares DOM elements for Chart. Moves to sibling -> Chart.sibling (Metrics).
6. beginWork(Metrics): Executes Metrics(). Has no children.
7. completeWork(Metrics): Prepares DOM elements for Metrics. Has no more siblings. Moves up -> Metrics.return (Dashboard).
8. completeWork(Dashboard): Bubbles up child effect flags. Moves up -> Dashboard.return (Root).
9. completeWork(Root): Root reconciliation complete. Work list ready for commit.

Traversal Order (beginWork): Root -> Navbar -> Dashboard -> Chart -> Metrics.

Step 2: Node Allocation vs Recycling via `createWorkInProgress()`

React never allocates brand new Fiber nodes for existing mounted components. Instead, it invokes createWorkInProgress(current, pendingProps):

• If current.alternate === null (initial render after mount): React allocates a new Fiber node and establishes the bidirectional link current.alternate = workInProgress and workInProgress.alternate = current.
• If current.alternate already exists (subsequent renders): React recycles the existing alternate node in place, resetting its effect flags (flags = NoFlags) and copying pendingProps.

Therefore, across all 5 visited nodes, 0 new Fiber objects are allocated on the heap; all 5 nodes are recycled via their alternate pointers.

Step 3: Bailout Mechanism on Unchanged `Navbar`

In beginWork(Navbar):

1. React checks if (current.lanes & renderLanes) === NoLanes (no direct updates pending on Navbar).
2. React checks oldProps === newProps (shallow reference equality).
3. If both are true, React calls bailoutOnAlreadyFinishedWork(current, workInProgress, renderLanes).
4. It checks (current.childLanes & renderLanes) === NoLanes. Since Navbar has no children with pending updates, React returns null, completely skipping Navbar and its entire subtree in O(1) time.

Step 4: Atomic Pointer Swap in Commit Phase

In commitRoot(root):

Once the physical DOM mutations are flushed synchronously, React executes the atomic pointer swap:

root.current = root.current.alternate; // Points to finished workInProgress tree

The newly committed tree is now current, and the old tree becomes available as the buffer for the next render.

Problem 2: React Lanes Priority Bitmask Mathematical Operations#

Context:

A React 19 concurrent runtime manages state updates across four predefined Lane constants:

const SyncLane               = 0b0000000000000000000000000000001; // 1 (Bit 0)
const InputContinuousLane    = 0b0000000000000000000000000000100; // 4 (Bit 2)
const DefaultLane            = 0b0000000000000000000000000010000; // 16 (Bit 4)
const TransitionLane1        = 0b0000000000000000000000100000000; // 256 (Bit 8)
const TransitionLane2        = 0b0000000000000000000001000000000; // 512 (Bit 9)

At timestamp t = 0, a component triggers a background data transition assigning TransitionLane1 and TransitionLane2 to the Fiber's pending lanes.

At timestamp t = 10 ms, an incoming network response schedules work on DefaultLane.

At timestamp t = 12 ms, a user clicks an input button, dispatching an immediate event on SyncLane.

Questions:

1. Express the combined pending lanes bitmask pendingLanes at t = 12 ms in both binary and decimal representations.
2. Demonstrate how the bitwise formula highestPriorityLane = lanes & -lanes isolates the single highest priority lane from pendingLanes. Show the two's complement arithmetic step-by-step.
3. Identify which update React executes immediately at t = 12 ms.
4. Once that highest-priority task commits, write the bitwise expression used to remove the completed lane from pendingLanes. Compute the remaining lanes bitmask.

Solution:

Step 1: Combined `pendingLanes` at t = 12 ms

Bitwise union (OR operation) of all four active lanes:

pendingLanes = TransitionLane1 | TransitionLane2 | DefaultLane | SyncLane

• TransitionLane1 = 0b0000000000000000000000100000000 (256)
• TransitionLane2 = 0b0000000000000000000001000000000 (512)
• DefaultLane = 0b0000000000000000000000000010000 (16)
• SyncLane = 0b0000000000000000000000000000001 (1)

Binary Representation:

pendingLanes = 0b0000000000000000000001100010001

Decimal Representation:

256 + 512 + 16 + 1 = 785.

Step 2: Two's Complement Isolation `lanes & -lanes`

Let L = 785 (0b...001100010001):

1. Invert all bits (One's complement ~ L):

~ L = 0b...110011101110

1. Add 1 (Two's complement -L):

-L = ~ L + 1 = 0b...110011101111

1. Bitwise AND (L\ \&\ -L):

```

0000000000000000000001100010001 (785)

& 1111111111111111111110011101111 (-785)

-----------------------------------

0000000000000000000000000000001 (SyncLane = 1)

```

Result: Exactly isolates Bit 0 (SyncLane).

Step 3: Immediate Execution Target

React evaluates highestPriorityLane = pendingLanes & -pendingLanes = SyncLane.

React suspends/aborts the background transition and immediately executes the user click (`SyncLane`) update.

Step 4: Clearing Completed Lane

To remove a completed lane from the bitmask, React performs a bitwise AND with the bitwise NOT of the completed lane:

pendingLanes = pendingLanes & ~SyncLane

Calculation:

• ~SyncLane = 0b1111111111111111111111111111110
• 785 & ~1 = 0b0000000000000000000001100010000

Decimal remaining = 785 - 1 = 784 (DefaultLane | TransitionLane1 | TransitionLane2).

On the next scheduler tick, 784 & -784 evaluates to 16 (DefaultLane), processing the network response next, before finally resuming the transition lanes (512 | 256).

Problem 3: Hook Linked-List State Machine & Update Queue Ring Buffer#

Context:

A functional React component is declared as follows:

function AccountDashboard() {
  const [balance, setBalance] = useState(100);
  const chartRef = useRef(null);
  const [currency, setCurrency] = useState("USD");
  useEffect(() => {
    /* fetch telemetry */
  }, [balance]);

  return <div>{balance} {currency}</div>;
}

During a user interaction event handler, the component dispatches three consecutive state updates before React initiates reconciliation:

setBalance(prev => prev + 50);
setBalance(prev => prev * 2);
setCurrency("EUR");

Questions:

1. Diagram the complete Fiber.memoizedState singly-linked list structure of Hook nodes after mount.
2. In Hook 1 (useState(100)), describe the data structure of hook.queue.pending. Why does React implement this queue as a circular linked list?
3. Trace the mathematical resolution of balance when the component re-renders. Show the reduction of the update queue from initial state to final memoizedState.
4. What is the state of currency after reconciliation?

Solution:

Step 1: Diagram of `Fiber.memoizedState` Hook List

Fiber.memoizedState
       |
       v
[Hook Node 0: useState (balance)]
  - memoizedState: 100
  - next -------------> [Hook Node 1: useRef (chartRef)]
                           - memoizedState: { current: null }
                           - next -------------> [Hook Node 2: useState (currency)]
                                                    - memoizedState: "USD"
                                                    - next -------------> [Hook Node 3: useEffect]
                                                                             - memoizedState: { create, deps: [100] }
                                                                             - next: null

Step 2: The Circular Linked List Structure of `hook.queue.pending`

The pending updates queue on a hook is structured as a circular singly-linked list:

• queue.pending points to the last update appended to the queue.
• Because it is circular, queue.pending.next points directly to the first update (the head of the queue).

Why Circular? This provides O(1) efficiency for both operations React requires:

1. Appending a new update to the tail: newUpdate.next = queue.pending.next; queue.pending.next = newUpdate; queue.pending = newUpdate; (O(1)).
2. Finding the head of the queue during reconciliation: firstUpdate = queue.pending.next (O(1)). Zero traversal loops required!

Step 3: State Reduction Trace for `balance`

Two updates are queued on Hook 0:

• Update 1: Action is function prev => prev + 50.
• Update 2: Action is function prev => prev * 2.

During the re-render pass:

1. Base state S_0 = 100.
2. Dequeue Update 1:

S_1 = Action_1(S_0) = 100 + 50 = 150.

1. Dequeue Update 2:

S_2 = Action_2(S_1) = 150 × 2 = 300.

1. Queue is exhausted.

Final memoizedState for Hook 0: `300`.

Step 4: State of `currency` (Hook 2)

Hook 2 receives Update 3: Action is constant "EUR".

Base state was "USD".

Evaluates action -> Sets memoizedState = "EUR".

Both state updates are flushed, and the component renders: <div>300 EUR</div>.

Problem 4: Frame Budget Execution & Concurrent Yield Latency Modeling#

Context:

An enterprise telemetry dashboard renders a dense data grid containing N = 1,200 individual component Fiber nodes.

• Reconciling each individual Fiber node in JavaScript takes an average of τ_{node} = 0.10 ms of CPU time.
• Total pure JavaScript reconciliation time:

T_{total} = 1,200 × 0.10 ms = 120.0 ms.

The application runs in a web browser targeting a 60 FPS refresh rate (16.67 ms frame interval).

The React Concurrent Scheduler allocates a maximum execution time slice of Δ t_{slice} = 5.0 ms before calling shouldYieldToHost() to check if the main thread must yield to the browser.

Each yield to the browser event loop (via MessageChannel.port1.postMessage) incurs a dispatch scheduling overhead of τ_{yield} = 0.5 ms.

Questions:

1. If this component were rendered under the legacy synchronous Stack Reconciler, how many 16.67 ms browser animation frames would be completely dropped, and what would happen if a user clicked a button at t = 20 ms?
2. Under the Concurrent Fiber Reconciler, calculate how many Fiber nodes are processed within a single 5.0 ms time slice.
3. Calculate the total number of slices required to complete the full 120.0 ms reconciliation pass.
4. Calculate the total wall-clock elapsed time from start to commit under Concurrent Fiber reconciliation.
5. If the user clicks a button at t = 20 ms that schedules an urgent SyncLane update taking 2.0 ms of CPU work, explain how React's scheduler handles the interruption and calculate the response latency experienced by the user.

Solution:

Step 1: Synchronous Stack Reconciler Frame Drops

Total blocking time = 120.0 ms.

Browser frame budget = 16.67 ms.

Frames dropped = 120.0 / 16.67 = 7.198 = 7 full frames dropped.

User Interaction at t = 20 ms: The browser main thread is locked in the synchronous recursive loop until t = 120.0 ms. The user's click event sits unacknowledged in the OS event buffer for 120.0 - 20.0 = 100.0 ms of perceived input lag, causing a noticeable UI freeze.

Step 2: Nodes Processed per 5.0 ms Time Slice

Time slice Δ t_{slice} = 5.0 ms.

Time per node τ_{node} = 0.10 ms.

Nodes per slice = Δ t_{slice} / τ_{node} = 5.0 / 0.10 = 50 nodes per time slice.

Step 3: Total Number of Slices Required

Total nodes = 1,200 nodes.

Slices required = 1,200 / 50 = 24 time slices.

Step 4: Total Wall-Clock Elapsed Time

Total time includes:

• Active execution time: 24 slices × 5.0 ms = 120.0 ms.
• Yield scheduling overhead: There are 23 yields between the 24 slices.

Yield overhead = 23 × 0.5 ms = 11.5 ms.

Total wall-clock time = 120.0 + 11.5 = 131.5 ms.

Step 5: Handling User Interaction at t = 20 ms

At t = 20 ms, React is currently completing Slice 4 (which runs from t = 16.5 ms to t = 21.5 ms):

1. At t = 21.5 ms, Slice 4 finishes. React invokes shouldYieldToHost(), which returns true.
2. React yields the main thread to the browser.
3. The browser processes pending native events and fires the user click event at t = 22.0 ms.
4. The click handler triggers a SyncLane update.
5. Because SyncLane (priority 1) has higher priority than the ongoing background transition, React immediately pauses the 1,200-node reconciliation.
6. React executes the urgent 2.0 ms SyncLane update from t = 22.0 ms to t = 24.0 ms and commits it to the DOM.
7. Total user input response latency = 24.0 - 20.0 = 4.0 ms (virtually instantaneous!).
8. At t = 24.5 ms, React resumes Slice 5 of the background data grid without any dropped frames or UI freezing.