Last year, I submitted a PR to React’s Fiber lanes implementation — mainly fixing a higherPriorityLane call and adding a few related tests. It ultimately got closed, but that ended up being the most valuable learning experience of my React career.

Digging into React’s source code, stepping through its priority scheduling system, and understanding why my approach didn’t align with the deeper reconciliation model taught me far more about how React actually works under the hood than years of application-level coding ever did.

Even though the PR wasn’t merged, the process gave me a much deeper appreciation of Fiber, lanes, and how React’s concurrency model is designed — and it’s shaped the way I write and reason about React code today.

Most developers (myself included, until recently) treat React as a black box. We know it uses a “Virtual DOM” and does some “diffing magic,” but the details feel academic — until they’re not. Until you’re debugging a performance issue, or wondering why your state updates aren’t batching the way you expect, or trying to understand why that useTransition hook makes your UI feel so much smoother.

So let me share what I learned from that PR. This isn’t just about Fiber lanes or reconciliation algorithms — it’s about understanding the mental model that powers every React application you’ll ever build.

Understanding React’s core algorithm and why it matters for writing performant code

You’ve heard it a thousand times:

React uses a Virtual DOM for performance.

But when pressed for details, most developers hand-wave something about “diffing” and “batching updates.” The truth is far more fascinating. React’s Fiber architecture is a complete rewrite of React’s core algorithm, introducing concepts like time-slicing, priority scheduling, and interruptible rendering that fundamentally change how we should think about React performance.

Understanding Fiber isn’t just academic curiosity — it directly impacts how you write performant React code. When you know how React schedules work, prioritizes updates, and decides what to render when, you can structure your components and state updates to work with React’s algorithm instead of against it. This deep dive reveals the inner workings that power every React application.

The Virtual DOM: More Than a Feeling

The Virtual DOM isn’t just a performance optimization — it’s a programming model that enables declarative UI:

// What the Virtual DOM actually is
interface VirtualNode {
  type: string | ComponentType; // 'div' or MyComponent
  props: Record<string, any>; // Including children
  key: string | null; // For list reconciliation
  ref: any; // Ref attachments
}

// Simplified Virtual DOM creation
function createElement(
  type: string | ComponentType,
  props: Record<string, any> | null,
  ...children: any[]
): VirtualNode {
  return {
    type,
    props: {
      ...props,
      children: children.length === 1 ? children[0] : children,
    },
    key: props?.key || null,
    ref: props?.ref || null,
  };
}

// What JSX compiles to
const jsxElement = <div className="card">Hello</div>;

// Becomes:
const virtualElement = createElement('div', { className: 'card' }, 'Hello');

// Component Virtual DOM
const ComponentVDOM = createElement(
  MyComponent,
  { name: 'React' },
  createElement('span', null, 'Child'),
);

The Reconciliation Process

// Simplified reconciliation algorithm
class SimpleReconciler {
  reconcile(
    oldVNode: VirtualNode | null,
    newVNode: VirtualNode | null,
    container: HTMLElement,
  ): void {
    // Deletion
    if (oldVNode && !newVNode) {
      this.removeNode(oldVNode, container);
      return;
    }

    // Addition
    if (!oldVNode && newVNode) {
      this.createNode(newVNode, container);
      return;
    }

    // Update
    if (oldVNode && newVNode) {
      // Different types: replace entirely
      if (oldVNode.type !== newVNode.type) {
        this.removeNode(oldVNode, container);
        this.createNode(newVNode, container);
        return;
      }

      // Same type: update properties and recurse on children
      this.updateNode(oldVNode, newVNode, container);
      this.reconcileChildren(oldVNode, newVNode, container);
    }
  }

  private reconcileChildren(
    oldVNode: VirtualNode,
    newVNode: VirtualNode,
    container: HTMLElement,
  ): void {
    const oldChildren = Array.isArray(oldVNode.props.children)
      ? oldVNode.props.children
      : [oldVNode.props.children];

    const newChildren = Array.isArray(newVNode.props.children)
      ? newVNode.props.children
      : [newVNode.props.children];

    // Key-based reconciliation for lists
    if (this.hasKeys(newChildren)) {
      this.reconcileKeyedChildren(oldChildren, newChildren, container);
    } else {
      // Index-based reconciliation (less efficient)
      this.reconcileIndexedChildren(oldChildren, newChildren, container);
    }
  }

  private reconcileKeyedChildren(
    oldChildren: VirtualNode[],
    newChildren: VirtualNode[],
    container: HTMLElement,
  ): void {
    // Build key maps for efficient lookup
    const oldKeyMap = new Map<string, VirtualNode>();
    oldChildren.forEach((child) => {
      if (child.key) oldKeyMap.set(child.key, child);
    });

    newChildren.forEach((newChild, index) => {
      const oldChild = oldKeyMap.get(newChild.key!);

      if (oldChild) {
        // Reuse existing node
        this.updateNode(oldChild, newChild, container);
        oldKeyMap.delete(newChild.key!);
      } else {
        // Create new node
        this.createNode(newChild, container);
      }
    });

    // Remove unused old nodes
    oldKeyMap.forEach((oldChild) => {
      this.removeNode(oldChild, container);
    });
  }
}

Fiber Architecture: The Game Changer

Fiber reimagines React’s reconciliation algorithm as an incremental, interruptible process:

// Fiber node structure (simplified)
interface FiberNode {
  // Instance
  tag: WorkTag; // Component type (Function, Class, Host, etc.)
  type: any; // Component constructor or DOM tag
  stateNode: any; // DOM node or class instance

  // Props and state
  pendingProps: any; // New props
  memoizedProps: any; // Previous props
  memoizedState: any; // Current state
  updateQueue: UpdateQueue | null; // Pending state updates

  // Effects
  flags: Flags; // Side effects to perform
  subtreeFlags: Flags; // Aggregated flags from subtree
  deletions: FiberNode[] | null; // Children to delete

  // Tree structure
  return: FiberNode | null; // Parent fiber
  child: FiberNode | null; // First child
  sibling: FiberNode | null; // Next sibling
  index: number; // Position in parent

  // Work in progress
  alternate: FiberNode | null; // Double buffering

  // Time and priority
  lanes: Lanes; // Priority of this update
  childLanes: Lanes; // Priority of children
  expirationTime: number; // When this work expires
}

// Work tags identify fiber type
enum WorkTag {
  FunctionComponent = 0,
  ClassComponent = 1,
  HostRoot = 3, // Root of the tree
  HostComponent = 5, // DOM elements
  HostText = 6, // Text nodes
  Fragment = 7,
  Mode = 8,
  ContextConsumer = 9,
  ContextProvider = 10,
  ForwardRef = 11,
  Profiler = 12,
  SuspenseComponent = 13,
  MemoComponent = 14,
  SimpleMemoComponent = 15,
  LazyComponent = 16,
}

// Flags track side effects
enum Flags {
  NoFlags = 0b0000000000000000000,
  PerformedWork = 0b0000000000000000001,
  Placement = 0b0000000000000000010,
  Update = 0b0000000000000000100,
  Deletion = 0b0000000000000001000,
  ChildDeletion = 0b0000000000000010000,
  ContentReset = 0b0000000000000100000,
  Callback = 0b0000000000001000000,
  DidCapture = 0b0000000000010000000,
  Ref = 0b0000000000100000000,
  Snapshot = 0b0000000001000000000,
  Passive = 0b0000000010000000000,
  LayoutMask = Update | Callback | Ref | Snapshot,
  PassiveMask = Passive | ChildDeletion,
}

The Fiber Work Loop

// Simplified Fiber work loop
class FiberScheduler {
  private workInProgressRoot: FiberNode | null = null;
  private workInProgress: FiberNode | null = null;
  private remainingExpirationTime: number = NoWork;
  private nextUnitOfWork: FiberNode | null = null;

  // Main work loop - can be interrupted
  workLoop(deadline: IdleDeadline): void {
    while (this.nextUnitOfWork !== null && (deadline.timeRemaining() > 0 || deadline.didTimeout)) {
      this.nextUnitOfWork = this.performUnitOfWork(this.nextUnitOfWork);
    }

    if (this.nextUnitOfWork === null) {
      // All work complete, commit to DOM
      this.completeRoot();
    } else {
      // More work to do, schedule continuation
      requestIdleCallback((deadline) => this.workLoop(deadline));
    }
  }

  // Process one fiber node
  private performUnitOfWork(fiber: FiberNode): FiberNode | null {
    // Phase 1: Begin work (traverse down)
    const next = this.beginWork(fiber);

    if (next !== null) {
      // Continue with child
      return next;
    }

    // No children, complete this fiber
    let completedWork: FiberNode | null = fiber;

    while (completedWork !== null) {
      // Phase 2: Complete work (traverse up)
      const returnFiber = completedWork.return;
      const siblingFiber = completedWork.sibling;

      this.completeWork(completedWork);

      if (siblingFiber !== null) {
        // Continue with sibling
        return siblingFiber;
      }

      // Continue completing parent
      completedWork = returnFiber;
    }

    return null;
  }

  private beginWork(fiber: FiberNode): FiberNode | null {
    switch (fiber.tag) {
      case WorkTag.FunctionComponent:
        return this.updateFunctionComponent(fiber);

      case WorkTag.ClassComponent:
        return this.updateClassComponent(fiber);

      case WorkTag.HostComponent:
        return this.updateHostComponent(fiber);

      case WorkTag.SuspenseComponent:
        return this.updateSuspenseComponent(fiber);

      default:
        return null;
    }
  }

  private updateFunctionComponent(fiber: FiberNode): FiberNode | null {
    const Component = fiber.type;
    const props = fiber.pendingProps;

    // Call the function component
    const children = Component(props);

    // Reconcile children
    return this.reconcileChildren(fiber, children);
  }

  private completeWork(fiber: FiberNode): void {
    // Mark effects that need to be applied
    if (fiber.flags & Flags.Update) {
      this.markUpdate(fiber);
    }

    if (fiber.flags & Flags.Placement) {
      this.markPlacement(fiber);
    }

    if (fiber.flags & Flags.Deletion) {
      this.markDeletion(fiber);
    }

    // Bubble up effects to parent
    if (fiber.return !== null) {
      fiber.return.flags |= fiber.flags;
      fiber.return.subtreeFlags |= fiber.subtreeFlags;
    }
  }

  // Commit phase - apply all effects to DOM
  private completeRoot(): void {
    const finishedWork = this.workInProgressRoot;
    if (finishedWork === null) return;

    // Commit all effects
    this.commitRoot(finishedWork);

    // Reset for next update
    this.workInProgressRoot = null;
    this.workInProgress = null;
  }

  private commitRoot(root: FiberNode): void {
    // Phase 1: Before mutation (getSnapshotBeforeUpdate)
    this.commitBeforeMutationEffects(root);

    // Phase 2: Mutation (DOM updates)
    this.commitMutationEffects(root);

    // Swap the tree
    root.current = root.alternate;

    // Phase 3: Layout (componentDidMount/Update)
    this.commitLayoutEffects(root);
  }
}

The Complete Picture: How React’s Systems Work Together

Understanding the Flow: A Bird’s Eye View

Most React explanations show you individual pieces — the Virtual DOM, Fiber nodes, the scheduler — but miss the crucial part: how they all connect. Let’s fix that.

The Four Systems and How They Connect

React’s performance story has four interconnected systems:

1. Update Queue System — Collects state changes
2. Batching System — Groups updates together
3. Scheduling System — Decides when work happens
4. Reconciliation System — Figures out what changed

Here’s how they work together:

┌─────────────────────────────────────────────────────────┐
│                    USER ACTION                          │
│                  (click, type, etc.)                    │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│ SYSTEM 1: UPDATE QUEUE                                  │
│                                                          │
│ setState(1) → Create update object                      │
│ setState(2) → Create update object                      │  
│ setState(3) → Create update object                      │
│                                                          │
│ All stored in: fiber.updateQueue.shared.pending         │
│ Structure: Circular linked list                         │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│ SYSTEM 2: BATCHING                                      │
│                                                          │
│ Question: Schedule reconciliation now or wait?          │
│                                                          │
│ If executionContext has BatchedContext flag:            │
│   → WAIT (don't schedule yet)                          │
│                                                          │
│ When batching context ends:                             │
│   → NOW schedule (once for all updates)                │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│ SYSTEM 3: SCHEDULING                                    │
│                                                          │
│ scheduleUpdateOnFiber() is called                       │
│   ↓                                                      │
│ Convert lane → scheduler priority                       │
│   ↓                                                      │
│ scheduleCallback(priority, performWorkOnRoot)           │
│   ↓                                                      │
│ Task created and pushed to scheduler's taskQueue        │
│                                                          │
│ Scheduler decides WHEN to execute based on priority     │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│ SYSTEM 4: RECONCILIATION                                │
│                                                          │
│ performWorkOnRoot() executes                            │
│   ↓                                                      │
│ For each fiber in tree:                                 │
│   • Process updates from updateQueue                    │
│   • Render component → new Virtual DOM                  │
│   • Diff with old Virtual DOM                           │
│   • Mark changes (flags)                                │
│   • Check: Should we pause? (priority check)            │
│   ↓                                                      │
│ Build work-in-progress tree with all changes marked     │
│   ↓                                                      │
│ Commit: Apply changes to DOM                            │
└─────────────────────────────────────────────────────────┘

System 1: The Update Queue

Every Fiber node has an update queue where state changes accumulate:

// Update queue structure
interface UpdateQueue<State> {
  baseState: State;           // Starting state
  shared: {
    pending: Update | null;   // Circular linked list of updates
  };
}

interface Update<State> {
  lane: Lane;                 // Priority (SyncLane, TransitionLane, etc.)
  action: State | ((prev: State) => State);
  next: Update | null;        // Next update in circular list
}

// When setState is called
function setState(newState) {
  // 1. Create update object
  const update = {
    lane: requestUpdateLane(),  // Gets current priority context
    action: newState,
    next: null
  };

  // 2. Add to fiber's circular linked list
  const fiber = getCurrentFiber();
  const pending = fiber.updateQueue.shared.pending;
  
  if (pending === null) {
    update.next = update;  // Points to itself (circular)
  } else {
    update.next = pending.next;  // Insert into circle
    pending.next = update;
  }
  
  fiber.updateQueue.shared.pending = update;  // Points to last update

  // 3. Try to schedule (goes to System 2: Batching)
  scheduleUpdateOnFiber(fiber, update.lane);
}

System 2: The Batching Mechanism

Batching is NOT about scheduler timeouts — it’s about delaying the scheduling call itself.

// React tracks execution context with flags
let executionContext = NoContext;

const NoContext = 0b000;
const BatchedContext = 0b001;   // "We're batching"
const RenderContext = 0b010;     // "We're reconciling"
const CommitContext = 0b100;     // "We're committing"

// React wraps event handlers
function dispatchEvent(nativeEvent) {
  // Turn ON batching flag
  const previousContext = executionContext;
  executionContext |= BatchedContext;

  try {
    // Your event handler runs here
    // All setState calls happen inside this try block
    invokeGuardedCallback(userProvidedEventHandler, nativeEvent);
  } finally {
    // Turn OFF batching flag
    executionContext = previousContext;

    // THIS IS THE KEY MOMENT
    if (executionContext === NoContext) {
      // Batching is complete, now schedule all accumulated updates
      flushSyncCallbackQueue();
    }
  }
}

// Inside setState's scheduling logic
function scheduleUpdateOnFiber(fiber, lane) {
  const root = markUpdateLaneFromFiberToRoot(fiber, lane);

  // CHECK: Are we batching?
  if (executionContext & BatchedContext) {
    // YES - Don't schedule yet, just return
    // The update is already in the queue, it will be
    // scheduled when the batch ends (in the finally block above)
    return;
  }

  // NO - Schedule immediately (goes to System 3)
  ensureRootIsScheduled(root, lane);
}

Why batching happens:

// Example: Three setState calls
function handleClick() {
  setState(1);  // Added to queue, scheduleUpdateOnFiber sees BatchedContext, returns
  setState(2);  // Added to queue, scheduleUpdateOnFiber sees BatchedContext, returns
  setState(3);  // Added to queue, scheduleUpdateOnFiber sees BatchedContext, returns
  // Function ends → finally block executes → flushSyncCallbackQueue()
  // → ONE call to ensureRootIsScheduled with ALL three updates
}

// Without batching:
function withoutBatching() {
  setState(1);  // Schedule immediately → Task 1 in queue
  setState(2);  // Schedule immediately → Task 2 in queue
  setState(3);  // Schedule immediately → Task 3 in queue
  // Three separate reconciliation passes!
}

React 18’s Automatic Batching:

// React 18 extends batching everywhere using microtasks
function ensureRootIsScheduled(root, lane) {
  // ... determine priority ...

  if (lane === SyncLane) {
    scheduleSyncCallback(performSyncWorkOnRoot);
    
    // Magic: Schedule flush in microtask queue
    if (executionContext === NoContext) {
      queueMicrotask(() => flushSyncCallbacks());
    }
  }
}

// Now even this batches:
setTimeout(() => {
  setState(1);  // Queued
  setState(2);  // Queued
  setState(3);  // Queued
  // setTimeout callback completes
  // → Microtask queue processes
  // → flushSyncCallbacks() runs
  // → ONE reconciliation
}, 1000);

System 3: The Scheduling Bridge

This is how the task queue gets populated

// The bridge from Fiber to Scheduler
function ensureRootIsScheduled(root: FiberRoot, lane: Lane) {
  // Step 1: Mark work on the root
  root.pendingLanes |= lane;

  // Step 2: Determine scheduler priority from React lane
  const schedulerPriority = lanesToSchedulerPriority(lane);

  // Step 3: THIS IS WHERE TASK QUEUE GETS POPULATED
  const callback = performConcurrentWorkOnRoot.bind(null, root);
  
  scheduleCallback(schedulerPriority, callback);
  // ↑ This is your PriorityScheduler.scheduleCallback from the article
}

// Convert React's lane system to Scheduler's priority system
function lanesToSchedulerPriority(lanes: Lanes): SchedulerPriority {
  // Find highest priority lane
  if (lanes & SyncLane) return ImmediatePriority;           // -1ms timeout
  if (lanes & InputContinuousLane) return UserBlockingPriority;  // 250ms
  if (lanes & DefaultLane) return NormalPriority;            // 5000ms
  if (lanes & TransitionLanes) return NormalPriority;        // 5000ms
  if (lanes & IdleLane) return IdlePriority;                // Never expires
  
  return NormalPriority;
}

// Inside your Scheduler (from the article)
class PriorityScheduler {
  scheduleCallback(priority: Priority, callback: Function): Task {
    const currentTime = performance.now();
    const timeout = this.timeoutForPriority(priority);
    const expirationTime = currentTime + timeout;

    // Create task object
    const task: Task = {
      id: this.taskIdCounter++,
      callback: callback,           // performConcurrentWorkOnRoot
      priority: priority,
      expirationTime: expirationTime,
      sortIndex: expirationTime
    };

    // THIS IS THE ANSWER: Task queue gets populated here
    this.push(this.taskQueue, task);  // Add to min-heap

    // Start processing if not already running
    if (!this.isPerformingWork) {
      this.requestHostCallback(this.flushWork);
    }

    return task;
  }
}

Lane Propagation — Why It Matters:

// Before scheduling, lanes must propagate up the tree
function markUpdateLaneFromFiberToRoot(fiber: FiberNode, lane: Lane): FiberRoot {
  // Mark the fiber that has the update
  fiber.lanes = mergeLanes(fiber.lanes, lane);

  // Walk up, marking all ancestors' childLanes
  let parent = fiber.return;
  while (parent !== null) {
    parent.childLanes = mergeLanes(parent.childLanes, lane);
    parent = parent.return;
  }

  return getRootForFiber(fiber);
}

// Why? During reconciliation, React can skip subtrees:
function beginWork(fiber, renderLanes) {
  // If this fiber's childLanes don't overlap with what we're rendering,
  // skip the entire subtree - no work here!
  if ((fiber.childLanes & renderLanes) === NoLanes) {
    return null;  // Bailout
  }

  // Has work, continue reconciling
  // ...
}

System 4: The Reconciliation Process

Now the scheduler executes the task, triggering reconciliation:

// Scheduler's work loop picks up the task
workLoop(deadline: IdleDeadline) {
  while (this.currentTask !== null && deadline.timeRemaining() > 0) {
    const callback = this.currentTask.callback;
    
    // Execute: performConcurrentWorkOnRoot(root)
    const continuationCallback = callback();
    
    if (continuationCallback) {
      // Work wants to continue (was interrupted)
      this.currentTask.callback = continuationCallback;
    } else {
      // Work complete
      this.pop(this.taskQueue);
    }
    
    this.currentTask = this.peek(this.taskQueue);
  }
}

// The reconciliation function
function performConcurrentWorkOnRoot(root: FiberRoot) {
  // Determine which lanes to render
  const lanes = getNextLanes(root, root.pendingLanes);
  
  // RENDER PHASE: Build work-in-progress tree
  renderRootConcurrent(root, lanes);
  
  // COMMIT PHASE: Apply changes to DOM
  if (workInProgressRootExitStatus === RootCompleted) {
    commitRoot(root);
  }
}

// The actual reconciliation loop
function renderRootConcurrent(root: FiberRoot, lanes: Lanes) {
  // Start at root
  let workInProgress = root.current.alternate;
  
  while (workInProgress !== null) {
    // Process this fiber
    workInProgress = performUnitOfWork(workInProgress);
    
    // Should we pause? Check priorities
    if (shouldYield()) {
      // Higher priority work arrived, pause here
      return RootIncomplete;
    }
  }
  
  return RootCompleted;
}

// Process one fiber node
function performUnitOfWork(fiber: FiberNode): FiberNode | null {
  // STEP 1: Process updates from updateQueue
  if (fiber.updateQueue !== null) {
    processUpdateQueue(fiber);
  }

  // STEP 2: Render component
  let nextChildren;
  if (fiber.tag === FunctionComponent) {
    const Component = fiber.type;
    nextChildren = Component(fiber.memoizedProps);
  }

  // STEP 3: Reconcile children (diff Virtual DOM)
  reconcileChildren(fiber, nextChildren);

  // STEP 4: Return next unit of work
  if (fiber.child !== null) {
    return fiber.child;  // Go down
  }
  
  // No children, go to sibling or up
  let node = fiber;
  while (node !== null) {
    completeWork(node);  // Mark effects
    
    if (node.sibling !== null) {
      return node.sibling;  // Go to sibling
    }
    
    node = node.return;  // Go up
  }
  
  return null;  // Tree complete
}

// Process the accumulated updates
function processUpdateQueue(fiber: FiberNode) {
  const queue = fiber.updateQueue;
  let firstUpdate = queue.shared.pending;
  
  if (firstUpdate === null) return;
  
  // Break circular list
  const lastUpdate = firstUpdate;
  const firstUpdateInQueue = lastUpdate.next;
  lastUpdate.next = null;
  
  // Apply each update
  let newState = queue.baseState;
  let update = firstUpdateInQueue;
  
  while (update !== null) {
    newState = getStateFromUpdate(update, newState);
    update = update.next;
  }
  
  // Store result
  fiber.memoizedState = newState;
  queue.shared.pending = null;
}

Priority and Scheduling

Fiber introduces priority-based scheduling to ensure high-priority updates (like user input) aren’t blocked by low-priority work:

// Priority levels in React
enum Lane {
  NoLane = 0b0000000000000000000000000000000,
  SyncLane = 0b0000000000000000000000000000001,
  InputContinuousLane = 0b0000000000000000000000000000100,
  DefaultLane = 0b0000000000000000000000000010000,
  TransitionLane1 = 0b0000000000000000000000001000000,
  TransitionLane2 = 0b0000000000000000000000010000000,
  IdleLane = 0b0100000000000000000000000000000,
  OffscreenLane = 0b1000000000000000000000000000000,
}

// Priority scheduler
class PriorityScheduler {
  private taskQueue: Task[] = [];
  private timerQueue: Task[] = [];
  private currentTask: Task | null = null;
  private isPerformingWork = false;

  scheduleCallback(priority: Priority, callback: () => void, options?: { delay?: number }): Task {
    const currentTime = performance.now();
    const startTime = currentTime + (options?.delay || 0);

    // Calculate timeout based on priority
    const timeout = this.timeoutForPriority(priority);
    const expirationTime = startTime + timeout;

    const task: Task = {
      id: this.nextTaskId++,
      callback,
      priority,
      startTime,
      expirationTime,
      sortIndex: -1,
    };

    if (startTime > currentTime) {
      // Delayed task
      task.sortIndex = startTime;
      this.push(this.timerQueue, task);

      if (this.taskQueue.length === 0 && task === this.peek(this.timerQueue)) {
        this.requestHostTimeout(this.handleTimeout, startTime - currentTime);
      }
    } else {
      // Immediate task
      task.sortIndex = expirationTime;
      this.push(this.taskQueue, task);

      if (!this.isPerformingWork) {
        this.isPerformingWork = true;
        this.requestHostCallback(this.flushWork);
      }
    }

    return task;
  }

  private timeoutForPriority(priority: Priority): number {
    switch (priority) {
      case Priority.Immediate:
        return -1; // IMMEDIATE_PRIORITY_TIMEOUT
      case Priority.UserBlocking:
        return 250; // USER_BLOCKING_PRIORITY_TIMEOUT
      case Priority.Normal:
        return 5000; // NORMAL_PRIORITY_TIMEOUT
      case Priority.Low:
        return 10000; // LOW_PRIORITY_TIMEOUT
      case Priority.Idle:
        return 1073741823; // IDLE_PRIORITY_TIMEOUT (never expires)
      default:
        return 5000;
    }
  }

  private flushWork(hasTimeRemaining: boolean, initialTime: number): boolean {
    this.isPerformingWork = true;

    try {
      return this.workLoop(hasTimeRemaining, initialTime);
    } finally {
      this.currentTask = null;
      this.isPerformingWork = false;
    }
  }

  private workLoop(hasTimeRemaining: boolean, initialTime: number): boolean {
    let currentTime = initialTime;
    this.advanceTimers(currentTime);

    this.currentTask = this.peek(this.taskQueue);

    while (this.currentTask !== null) {
      if (
        this.currentTask.expirationTime > currentTime &&
        (!hasTimeRemaining || this.shouldYieldToHost())
      ) {
        // This task hasn't expired, and we've run out of time
        break;
      }

      const callback = this.currentTask.callback;

      if (typeof callback === 'function') {
        this.currentTask.callback = null;
        const continuationCallback = callback();

        if (typeof continuationCallback === 'function') {
          // Task wants to continue
          this.currentTask.callback = continuationCallback;
        } else {
          // Task complete
          if (this.currentTask === this.peek(this.taskQueue)) {
            this.pop(this.taskQueue);
          }
        }
      } else {
        this.pop(this.taskQueue);
      }

      this.currentTask = this.peek(this.taskQueue);
      currentTime = performance.now();
    }

    // Return whether there's more work
    return this.currentTask !== null;
  }

  private shouldYieldToHost(): boolean {
    const currentTime = performance.now();
    return currentTime >= this.deadline;
  }

  // Min-heap operations for priority queue
  private push(heap: Task[], task: Task): void {
    const index = heap.length;
    heap.push(task);
    this.siftUp(heap, task, index);
  }

  private peek(heap: Task[]): Task | null {
    return heap.length === 0 ? null : heap[0];
  }

  private pop(heap: Task[]): Task | null {
    if (heap.length === 0) return null;

    const first = heap[0];
    const last = heap.pop()!;

    if (last !== first) {
      heap[0] = last;
      this.siftDown(heap, last, 0);
    }

    return first;
  }
}

Concurrent Mode Features

Concurrent Mode leverages Fiber’s architecture to enable powerful features:

// Time Slicing Example
function TimeSlicingDemo() {
  const [isPending, startTransition] = useTransition();
  const [inputValue, setInputValue] = useState('');
  const [list, setList] = useState<string[]>([]);

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    // High priority - immediate update
    setInputValue(e.target.value);

    // Low priority - can be interrupted
    startTransition(() => {
      const newList = [];
      for (let i = 0; i < 20000; i++) {
        newList.push(e.target.value);
      }
      setList(newList);
    });
  };

  return (
    <div>
      <input value={inputValue} onChange={handleChange} />
      {isPending && <span>Updating list...</span>}
      <ul>
        {list.map((item, index) => (
          <li key={index}>{item}</li>
        ))}
      </ul>
    </div>
  );
}

// Suspense with Fiber
function SuspenseWithFiber() {
  // Fiber can pause rendering when a promise is thrown
  return (
    <Suspense fallback={<Loading />}>
      <AsyncComponent />
    </Suspense>
  );
}

function AsyncComponent() {
  const data = use(fetchData()); // Throws promise if not ready

  // Fiber will:
  // 1. Catch the promise
  // 2. Show fallback
  // 3. Resume rendering when promise resolves
  return <div>{data}</div>;
}

How Fiber Impacts Performance

Batching and Auto-batching

// React 18+ automatic batching
function AutoBatchingExample() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  // Before React 18: 2 renders
  // React 18+: 1 render (automatic batching)
  const handleClick = () => {
    setCount((c) => c + 1);
    setFlag((f) => !f);
    // Both updates batched automatically
  };

  // Even in async code!
  const handleAsyncClick = async () => {
    const data = await fetchData();

    // Still batched in React 18+
    setCount(data.count);
    setFlag(data.flag);
  };

  // Opt out of batching when needed
  const handleImmediateUpdate = () => {
    flushSync(() => {
      setCount((c) => c + 1);
    }); // Forces immediate render

    // This runs after count is updated
    setFlag((f) => !f);
  };

  return (
    <div>
      <p>Count: {count}, Flag: {flag.toString()}</p>
      <button onClick={handleClick}>Update Both</button>
    </div>
  );
}

Optimizing for Fiber’s Algorithm

// Component structured for Fiber optimization
function FiberOptimizedComponent({ data }: { data: Item[] }) {
  // 1. Stable keys for efficient reconciliation
  const items = useMemo(
    () =>
      data.map((item) => ({
        ...item,
        key: item.id, // Stable key
      })),
    [data],
  );

  // 2. Priority-aware updates
  const [search, setSearch] = useState('');
  const [deferredSearch] = useDeferredValue(search);

  // 3. Interrupt-friendly expensive computation
  const filtered = useMemo(
    () => 
      items.filter((item) => 
        item.name.toLowerCase().includes(deferredSearch.toLowerCase())
      ),
    [items, deferredSearch],
  );

  // 4. Leverage suspense for data fetching
  return (
    <div>
      <input
        value={search}
        onChange={(e) => setSearch(e.target.value)}
        placeholder="Search (high priority)"
      />

      <Suspense fallback={<Skeleton />}>
        <ItemList items={filtered} />
      </Suspense>
    </div>
  );
}

// Understanding bailout optimization
function BailoutOptimization({ value }: { value: number }) {
  console.log('Parent render');

  // Fiber can skip rendering children if props haven't changed
  return (
    <>
      <ExpensiveChild /> {/* Skipped if no props change */}
      <CheapChild value={value} />
    </>
  );
}

const ExpensiveChild = memo(() => {
  console.log('ExpensiveChild render');
  // Complex computation...
  return <div>Expensive</div>;
});

Debugging Fiber Internals

// Accessing Fiber internals (development only)
function FiberDebugger({ children }: { children: React.ReactNode }) {
  const ref = useRef<HTMLDivElement>(null);

  useEffect(() => {
    if (process.env.NODE_ENV === 'development') {
      // Access fiber node
      const fiberNode =
        (ref.current as any)?._reactInternalFiber || (ref.current as any)?._reactInternalInstance;

      if (fiberNode) {
        console.group('Fiber Node Structure');
        console.log('Type:', fiberNode.type);
        console.log('Tag:', fiberNode.tag);
        console.log('Props:', fiberNode.memoizedProps);
        console.log('State:', fiberNode.memoizedState);
        console.log('Effects:', fiberNode.flags);
        console.log('Priority:', fiberNode.lanes);
        console.groupEnd();

        // Traverse fiber tree
        traverseFiberTree(fiberNode);
      }
    }
  }, []);

  return <div ref={ref}>{children}</div>;
}

function traverseFiberTree(fiber: any, depth = 0) {
  const indent = '  '.repeat(depth);
  console.log(`${indent}${fiber.type?.name || fiber.type || 'Unknown'}`);

  // Traverse children
  let child = fiber.child;
  while (child) {
    traverseFiberTree(child, depth + 1);
    child = child.sibling;
  }
}

// Performance marks for Fiber phases
function measureFiberPhases() {
  if (typeof window !== 'undefined' && window.performance) {
    // React adds marks during rendering
    const marks = performance.getEntriesByType('mark');
    const reactMarks = marks.filter(
      (mark) => mark.name.startsWith('⚛') || mark.name.includes('React'),
    );

    console.table(
      reactMarks.map((mark) => ({
        name: mark.name,
        startTime: mark.startTime,
        duration: mark.duration,
      })),
    );
  }
}

Practical Fiber Optimizations

// 1. Structure components for efficient reconciliation
function EfficientList({ items }: { items: Item[] }) {
  return (
    <div>
      {items.map((item) => (
        // Stable key = efficient reconciliation
        <Item key={item.id} {...item} />
      ))}
    </div>
  );
}

// 2. Use lanes for priority
function PriorityAwareComponent() {
  const [urgent, setUrgent] = useState('');
  const [deferred, setDeferred] = useState('');

  return (
    <div>
      <input
        value={urgent}
        onChange={(e) => {
          // Sync lane - highest priority
          setUrgent(e.target.value);
        }}
      />

      <button
        onClick={() => {
          // Transition lane - lower priority
          startTransition(() => {
            setDeferred(processData(urgent));
          });
        }}
      >
        Process
      </button>
    </div>
  );
}

// 3. Minimize fiber tree depth
// ❌ Deep nesting = more fiber nodes
function DeepNesting() {
  return (
    <div>
      <div>
        <div>
          <div>
            <Content />
          </div>
        </div>
      </div>
    </div>
  );
}

// ✅ Flat structure = fewer fiber nodes
function FlatStructure() {
  return (
    <div className="container">
      <Content />
    </div>
  );
}

// 4. Leverage Suspense boundaries
function SuspenseBoundaries() {
  return (
    <div>
      {/* Each boundary can work independently */}
      <Suspense fallback={<HeaderSkeleton />}>
        <Header />
      </Suspense>

      <Suspense fallback={<ContentSkeleton />}>
        <Content />
      </Suspense>

      <Suspense fallback={<SidebarSkeleton />}>
        <Sidebar />
      </Suspense>
    </div>
  );
}

Wrapping Up

The Virtual DOM and Fiber architecture are the beating heart of React’s performance story. The Virtual DOM provides the declarative programming model we love, while Fiber transforms that model into an efficient, interruptible, priority-aware rendering machine. Understanding these internals isn’t just academic — it directly informs how you structure components, manage state, and optimize performance.

The key insights: React can interrupt and resume work, different updates have different priorities, and the reconciliation algorithm rewards stable keys and shallow component trees. Write your React code with these principles in mind, and you’re working with the framework’s natural grain rather than against it.

Master Fiber’s mental model, and you’ll write React applications that aren’t just fast — they’re predictably fast, gracefully handling everything from smooth animations to massive lists without breaking a sweat.

useState is the most commonly used hook one would like to reach out in React for doing state Management, In this Article, we would try to write our own useState hook and understand how it works under the hood. This is just for educational purpose, In real life circumstances we should not try to do custom implementation of things which already exist unless there is a specific constraint.

Let start by Drafting the Structure of useState

function useState(initivalValue) {
   // need to do something that helps us do re-renders
   // return use the currentStateValue and state Updater function
}

So how we can go about solving this? When it comes to React there is a useReducer method, which helps us Separate our state Update logic and applies a reducer pattern to modify states. now why do we need to use useReducer to build a useState hook, we will see it later, lets start writing the logic for our useState.

import { useRef } from "react";

function useState(initivalValue) {
   const stateRef = useRef(initialValue); 
   
   // remaining Main logic
}

we need to first preserve the initialValue such that it does not get changed in any case, refs are best way to preserve values, now as we talked about useReducer, it gives us a very powerful function called as dispatch function which can trigger re-render, like calling dispatch(), is like saying to react to trigger render and update our DOM. Even useState under the hood uses the same method to trigger the re-render. so lets complete our useStateHook

import { useRef,useReducer } from "react";

function useState(initivalValue) {
   const stateRef = useRef(initialValue); 
   const [_,forceRender] = useReducer((b) => !b,false)
}

now we have used the useReducer hook, it takes a reducer callback and an initial Value similar to our Reducer function available on Array prototype, what we do inside the callback in our context is not important, as we just want to safely retrieve the dispatch method which we are calling forceRender. Now the only thing left to do is making our StateUpdater method and returning our state value and its UpdaterMethod. Lets complete it.

import { useRef, useReducer } from "react";

export function useState(initialValue) {
  const stateRef = useRef(initialValue);
  const [, forceRender] = useReducer((b) => !b, false);

  const setState = (newValue) => {
      stateRef.current = newValue;
      forceRender();
  };

  return [stateRef.current, setState];
}

The SetState method is pretty straight forward, it takes the newValue as the argument and replaces our stateRef Value with the same and then eventually call the forceRender() method and eventually Return the stateValue and stateUpdaterFunction.

We are almost there, but there is a slight issue in our useState hook as of now, and let me explain the issue, in React when we use useState, it only triggers the re-render, if the previousStateValue and currentStateValue differs.

import {useState} from 'react'

const App = () => {
  const [count,setCount] = useState(0)

  function IncrementCount() {
      setCount(0) // This won't trigger re-render
   }

  return(
     <>
      <p>{count}</p>
      <button onClick={IncrementCount}>increment</button>
    </>
   )

}

But if we try to see our own useState hook, this is not the case

import { useRef, useReducer } from "react";

export function useState(initialValue) {
  const stateRef = useRef(initialValue);
  const [, forceRender] = useReducer((b) => !b, false);

  const setState = (newValue) => {
      stateRef.current = newValue;
      forceRender();
  };

  return [stateRef.current, setState];
}

whenever we are calling the SetState, we just directly update the value and call the forceRender which is not correct, and the fix is pretty simple and something which even React under the hood uses, we can try to compare the two Values whether both are equal and we would use the Object.is method over our StateRef value and newValue to determine the same, and only if the result of calling Object.is is false, we would set our stateRef to our newValue and force Re-render.

import { useRef, useReducer } from "react";

export function useState(initialValue) {
  const stateRef = useRef(initialValue);
  const [, forceRender] = useReducer((b) => !b, false);

  const setState = (newValue) => {
    if (Object.is(stateRef.current, newValue) === false) {
      stateRef.current = newValue;
      forceRender();
    }
  };

  return [stateRef.current, setState];
}

now this actually completes our implementation of our useState Hook, in practice there are lot of things React does with useState which simply out of my understanding, but this can give you a better mental model of what useState does under the hood, The amazing part about all of this is React is not doing any magic under the hood, its using already existing JavaScript patterns to simplify how we write and think about UI. That’s it for this article, Hope you enjoyed reading this.

In React, re-renders are the only way your React components get updated with the Latest Data, without re-renders, your app is static. we are going to understand how passing Elements as Props in React helps us with performance, Before diving into the topic of this Blog, let us understand two crucial terms we need to have good understanding to make sense of this blog

What is a React Component ?

React components in a nutshell are functions, just like in JavaScript, but unlike regular functions they return us React Elements.

function Button() {
  return (
    <button>Click Me</button>
    )
}

// Button here is a Component

what is a React Element?

Every React Component if it want to render something has to return Element, the Element can be a React component itself or a Valid HTML DOM element, This Elements are just Plain JavaScript Objects. They have a special Syntax where they are wrapped between Angle Brackets Just like Regular DOM Elements.

function Footer() {
const [date, setDate] = useState(new Date())
  return (
     <>
     {date}
    <Button />
     </>
    )
}

// Button is the Element Here
// The Footer Component can also become an Element like <Footer />

Under the Hood when React Calls a component either in case of initial render or re-rendering, the component call returns the Object as we discussed above, which React would use to generate a tree of these Objects, this is what is referred to as the Virtual DOM, in case of subsequent Renders, React generates Two trees, Before Render and After Render.

if you try to paste any Component inside Babel Playground, you will get to see internally the returned Values, are Just Plain React.createElement calls in our case it would look like React.createElement(“Button”, null, null)

Under the Hood when React Calls a component either in case of initial render or re-rendering, the component call returns the Object as we discussed above, which React would use to generate a tree of these Objects, this is what is referred to as the Virtual DOM, in case of subsequent Renders, React generates Two trees, Before Render and After Render.

To perform reconciliation, React would compare these two tree to seek information it would apply to the DOM to add, delete or update the DOM as it requires. The Objects returned eventually becomes what we see on the Screen and the Object has a special Structure Like Below

{
 type: "Button",
 props : {},
 // More Internal Stuff Used by React
}

Now let us see what would happen during reconciliation when we call our Footer Component, the whole Footer component runs, the state is instantiated, once we reach the Button Element, React will run the diffing process, calling Object.is over beforeRender and AfterRender, in this case every time in memory a new Object is generated for the Button Element, which means the comparison will result in False, which signals react to re-render as something has changed.

function Footer() {
const [date, setDate] = useState(new Date())
  return (
     <>
     {date}
    <Button />
     </>
    )
}

if the type key as we see above has not changed, it will just re-render the component with the new attributes as required, however if the type has changed it means it needs to delete the existing DOM attached to it and mount the new one.

Time to unwrap the central agenda of this Blog how passing the Element as Props can help us with Performance, now lets change something

function Footer({Button}) {
const [date, setDate] = useState(new Date())
  return (
     <>
     {date}
    <Button />
     </>
    )
}

// Somewhere Above the Code

<Footer Button={Button}/>

Let us run through the Whole reconciliation process once more, this time we are passing the Button from outside the Footer component, as a reference, so when the Diffing process runs, state is instantiated, and then calling Object.is called over the beforeRender and afterRender on the returned value, this time the Button Object is created outside the Footer function scope, and so it won’t change when Footer gets called, which results the expression in True, which signal react to skip re-render of this component.

This was a very simple example, but it is a very powerful technique in my opinion when you just can’t simply lift the state down to minimise re-renders to achieve performance, though passing elements as Props might feel weird and invalid, so React has another special syntax which does the same thing.

function Footer({children}) {
const [date, setDate] = useState(new Date())
  return (
     <>
     {date}
     {children}
     </>
    )
}

// Somewhere Above the Code

<Footer>
 <Button/>
<Footer/>

In the Above code now, we are using a special reserved prop called children which allow us to pass React Elements explicitly in a nested manner, this is a better syntax in my opinion, and we get the same performance benefits as we saw, this is just a syntactic sugar.

<Footer Button={Button}/>

// The above is same as Below

<Footer>
<Button/>
</Footer>

I hope i was able to explain the performance benefits of passing Elements as Props, its more related to how JavaScript works, if you have doubts regarding the same feel free to comment your doubt, i will come up with More React related internal blogs.

Thanks for Reading.