DEV Community: Neha Malvia

Part 3 - Concurrent Rendering & Lanes (React 18)

Neha Malvia — Tue, 17 Mar 2026 12:57:19 +0000

In the previous parts, we saw how Fiber (React 16) broke the rendering work into small chunks. It gave React the ability to pause, but the engine was still "Sequential." It worked on one task at a time, just with better interruptions.

React 18 changes the fundamental nature of time in React. It moves us from a "Sequential" world to a "Concurrent" one.

1. The React 16 Foundation: Fiber Root & Pausable Work

In React 16, we introduced the Fiber architecture. This gave us the "Work-in-Progress" tree and "Current" tree.

The Mechanism: React could pause the "Render" phase to let the browser paint a frame, then resume.
The Limit: Updates were prioritized using a simple countdown called Expiration Times. It was a linear queue where one update had to "win" over another.

2. The React 18 Solution: Concurrency & the "Lanes" Model

React 18 replaces "Expiration Times" with a Lanes Model.

How the Lanes Model Works:

Instead of a single timestamp for when an update expires, React now performs bitmask operations to group and filter work. Each "lane" represents a category of priority using a 32-bit integer.

Bitwise Priority: React assigns a specific bit to each type of task. For example:
- Sync Lane: 0b0000000000000000000000000000001 (Immediate updates like typing).
- InputContinuous Lane: Used for things like scrolling or zooming.
- Default/Transition Lane: For data fetching or heavy list rendering.
Multitasking & Interleaving: Because these are bits, React can combine multiple lanes into a single "bundle" of work (e.g., handling three different transitions at once). If React is working on a "Transition Lane" and a user types in a search box, a "Sync Lane" bit is flipped. React sees this bit has a higher mathematical priority, pauses the transition work immediately, handles the keystroke, and then returns to the transition work.
The Highway Analogy: Think of the Lanes Model as a 32-lane highway. Different types of updates travel in their own dedicated lanes. Urgent updates (like typing) get priority lanes and can quickly "bypass" slower traffic (like background data fetching) in adjacent lanes.
Entanglement: If two updates depend on each other, React can "entangle" their lanes, forcing them to finish together so the UI doesn't look inconsistent.

3. Key Features Enabled by Concurrency

Automatic Batching
Previously, React only batched updates inside event handlers. React 18 now batches everything—even inside fetch(), setTimeout(), or native events. This cuts down on unnecessary re-renders by grouping multiple state changes into one single render pass.

Transitions (useTransition)
This is the most "human" part of the update. You can now explicitly tell React: "This update is not urgent."

While the transition is rendering in the background, the UI remains interactive.
Benefit: No more "janky" inputs while a heavy list is filtering.

Selective Hydration: Smarter Server-Side Rendering
React 18 also fixed the "All-or-Nothing" problem of SSR.

The Old Way: You had to download and hydrate the entire page before you could click a single button.
The New Way: Using <Suspense>, React can now stream HTML and selectively hydrate components.
The Benefit: If a user clicks a component that hasn't hydrated yet, React will "jump the lane" and hydrate that specific component first.

4. Why it is Beneficial

Decoupled Rendering: You can start a heavy render in the background without freezing the input field.
Predictive UI: React can "prepare" a screen in a hidden lane while the user is still looking at the old screen, switching only when the new one is ready (this is the core of Suspense).
No More "Jank": By splitting work into these 32 lanes, React ensures that high-frequency events (like mouse moves) always have a free lane to bypass slow computations.

Comparison: Expiration Times vs. Lanes

Feature	Expiration Times (React 16)	Lanes Model (React 18)
Logic Type	Linear / Queue-based	Bitwise / Category-based
Multitasking	Sequential: One update at a time	Concurrent: Multiple updates can overlap
Priority Handling	Based on "age" (how long it's waited)	Based on "type" (User Input vs. Background)
Interruption	Limited: Hard to resume partially done work	Advanced: Can pause, branch, and resume work
Relationship	Updates are independent	Updates can be "entangled" together

Conclusion: Mastering the Dimension of Time

React 18 didn't just make the engine faster; it made it smart. By moving from a simple "pausable" queue to a 32-lane Concurrent system, React evolved from a basic UI library into a sophisticated scheduler.

By mastering Bitmasks and Lanes, you’ve moved beyond basic state management. You now understand how React manages the most precious resource in the browser: Main Thread Time.

However, even with a smart engine, we still spend hours manually tweaking performance with useMemo and useCallback. In the final part of this series, we’ll look at the React 19 Compiler—the evolution that turns React from a library you have to optimize into one that finally optimizes itself.

📚 Deep Dive References
If you want to see the original "blueprints" for Concurrent React, these are the essential reads:

React 18 Official Release Post: The high-level overview of the Concurrency shift. React v18.0 Release
The Lanes Model (Original PR): The actual bitwise logic that replaced Expiration Times. React PR #18796 - Initial Lanes Implementation
New Suspense Architecture: Deep dive into Selective Hydration and Streaming SSR. React WG - Selective Hydration Deep Dive
The Transition API: How to talk to the Lanes model directly from your code. react.dev - useTransition Reference

Part 2 - The Fiber Revolution (React 16)

Neha Malvia — Sun, 25 Jan 2026 07:38:40 +0000

In React 15, we hit a wall: the "Stack" was too rigid. We realized we needed to decouple Diffing (calculating changes) from Patching (writing to the DOM). More importantly, we needed the ability to pause execution for high-priority tasks like user input.

React 16 introduced Fiber—a complete rewrite of the core reconciliation engine. Fiber allows React to pause, resume, and prioritize work, giving "wings" to the user experience.

1. The Foundation: What is a "Fiber"?

To understand Fiber, we must first distinguish between a React Element and a Fiber Node.

React Element

These are plain JavaScript objects returned from render(). They are immutable. Every time a component renders, React throws away the old elements and creates new ones.

Fiber Node

A Fiber Node is a mutable internal object that represents the "real" state of your application. It acts as the unit of work. While elements are recreated, Fiber nodes are reused and persistent. They represent the actual UI components on the screen.

If you looked inside a Fiber node, you would see these key technical fields:

stateNode: The actual DOM element or class instance.
type: The function or class associated with the fiber.
pendingProps vs memoizedProps: "New data" coming in vs "Current data" already rendered.
updateQueue: A linked list of state changes waiting to be processed.
effectTag: A bitmask (e.g., 0b001) that tracks what needs to be done (Placement, Update, etc.).

The Linked List Structure

Fiber replaced the old recursive tree with a Singly Linked List. Each Fiber node has three critical pointers that allow React to traverse the tree without using the JavaScript Call Stack:

Child: Points to the first child.
Sibling: Points to the next sibling.
Return: Points back to the parent.

2. The Internal Engine: The Work Loop

The Work Loop is the heart of React 16. It manages how much time is spent on reconciliation using Cooperative Scheduling.

shouldYield(): The loop constantly asks the browser: "Do you have urgent work for me?" (via requestIdleCallback). If the browser needs to paint a frame, React pauses.
Expiration Times: React 16 used Expiration Times to prioritize updates. A user typing gets an earlier expiration (High Priority) than a data fetch (Low Priority).

3. The Two-Phase Reconciliation Process

React 16 fundamentally splits rendering into two distinct phases. This is the "secret sauce" that allows for interruptible rendering.

Phase 1: The Render Phase (Interruptible)

This phase is asynchronous. React traverses the existing Fiber tree (the "Current" tree) and calculates exactly what needs to change. During this traversal, React is doing two massive things: Creating the WIP Tree and Building the Effect List.

1. The Trigger: State Update

When setState is called, React creates an Update Object, places it in the updateQueue of that Fiber, and signals the scheduler. React then starts at the HostRoot and begins creating a Work-In-Progress (WIP) Tree. This WIP tree is a "draft" version of the Fiber nodes that will eventually replace the Current tree.

2. The unit of work: beginWork()

React moves down the tree calling beginWork() for each fiber node.

Cloning: React clones the Fiber from the "Current" tree into the "WIP" tree.
Bailout: If pendingProps equals memoizedProps and there's no update in the queue, React "bails out" and skips that subtree, simply reusing the old nodes.
Diffing & Effect Tags: If changes are found, React calculates the difference and marks the WIP Fiber with an Effect Tag using a bitmask (e.g., Placement, Update).

3. Prioritization & Interruption

Because React is working on a WIP Tree in the background, it can afford to be interrupted. If a high-priority event (like a keystroke) arrives, React pauses the creation of the WIP tree.

If the high-priority work doesn't affect the data React was just calculating, it resumes the WIP tree.
If it does change the same data, React discards the half-finished WIP tree and starts fresh.

4. The Backtrack & The Effect List: completeWork()

Once React reaches a leaf node (no more children), it starts moving back up the tree via completeWork(). This is where the Effect List is born.

Physical Preparation: React prepares the DOM nodes for the WIP fiber (but does not touch the screen yet).
The "Christmas Lights" (Effect List): As React backtracks, it collects all the Fibers that have Effect Tags and links them together into a linear linked list.
The Benefit: By the time React reaches the Root, it has a separate, tiny list of "dirty" nodes. It doesn't need to look at the whole tree anymore; it just needs to follow this list.

Phase 2: The Commit Phase (Synchronous)

Now that the "Math" is done and the WIP Tree is ready, React enters the Commit Phase. This is synchronous and uninterruptible to prevent visual glitches.

5. DOM Updates & The Swap

DOM Update: React follows the Effects List (the shortcut) to jump directly to nodes that need changing.
Double Buffering (The Swap): React maintains two trees: Current (on screen) and WIP (the draft). Once the DOM is patched, React performs a "Pointer Swap":

FiberRoot.current = WorkInProgressTree

Instantly, the "Draft" becomes the new reality.

6. Post-Update Lifecycles

React runs side effects: componentDidMount, componentDidUpdate, and updates refs. The main thread is then released back to the browser.

Conclusion: From Blocking to Cooperative

React 16 didn't just add features; it gave React a brain. By moving from a rigid "Stack" to a flexible "Linked List" of Fibers, React stopped being a blocking force and became a cooperative citizen of the browser.

The secret was making the update process Asynchronous. Instead of finishing the whole UI in one go, React learned to:

Break work into tiny chunks (Fiber nodes).
Pause if the browser had something more important to do.
Draft the new UI in the background (WIP Tree) without touching the screen.
Commit everything in one lightning-fast, synchronous burst.

By understanding beginWork, completeWork, and effectTag bitmasks, you’ve mastered the mechanics of the Fiber engine. But while React 16 gave us the engine, it didn't yet have the smart "traffic control" system to handle multiple updates at once.

In the next part, we’ll see how React 18 took this Fiber engine and added "Lanes"—the traffic control system that finally unlocked the full power of Concurrent React.

📚 Deep Dive References

If you want to look at the original documents that inspired this architecture, I highly recommend these:

The Fiber Architecture (The Official Design Doc): Written by Andrew Clark, this is the original blueprint that explained why React needed a rewrite.
- Link: React Fiber Architecture on GitHub
Lin Clark’s "A Cartoon Guide to Fiber": This is the most famous explanation of the Fiber algorithm ever created. It’s perfect for visual learners.
- Link: A Cartoon Guide to Fiber (React Conf 2017)
Inside Fiber: In-depth overview of the new reconciliation algorithm: A legendary technical blog by Max Koretskyi that dives into the source code of beginWork and completeWork.
- Link: Inside Fiber - Indepth Overview

Part 1 — The Era of the Stack Reconciler

Neha Malvia — Mon, 19 Jan 2026 17:35:49 +0000

React 15 was defined by the Stack Reconciler. During this era, the update process was synchronous and uninterruptible. Once a state update started, React was like a high-speed train with no brakes; it couldn't pause, even if the tracks were blocked.

The High-Level Process
React maintains an in-memory tree (the Virtual DOM) that represents your component hierarchy. When an update occurs, React creates a new Virtual DOM, compares it with the previous version, and calculates the minimum number of changes needed to update the Real DOM.

Deep Diving into the Reconciliation Process
To understand why this architecture eventually hit a ceiling, we need to look at how it handled updates internally.

1. The Trigger: this.setState()
The moment a component calls this.setState(), it’s a "go" signal. React immediately begins the process of figuring out what changed for that specific component and its entire subtree.

2. The Recursive "Dive"
To understand the UI changes, React calls the render() method. Because components are nested, this triggers a recursive chain:

If Component A has a child Component B, React calls A.render(), then immediately dives down to call B.render().
Each of these function calls is pushed onto the JavaScript Call Stack.

The Crucial Constraint: JavaScript is single-threaded. If the Call Stack is occupied by React’s recursion, the browser cannot handle user inputs like scrolling or clicking a "Cancel" button. The main thread is "held hostage" until the stack is completely empty.

3. Generating the Virtual DOM
As the recursion moves down the tree, React produces a brand-new Virtual DOM. This is a lightweight, in-memory JavaScript object representing the "desired" state of the UI at that exact moment.

4. Synchronous Diffing & Immediate DOM Patching
This is the most critical part of the React 15 architecture. In the Stack Reconciler, Diffing (finding the difference) and Patching (updating the screen) happened simultaneously.

As the algorithm walked the tree and found a difference—for example, a <div> changing to a <span>—it would immediately call document.setAttribute or appendChild to update the Real DOM right then and there.

Because React was mutating the Real DOM while still calculating the rest of the tree, the process was impossible to pause. You couldn't stop halfway because you had already started changing what the user sees on their screen!

The Performance Bottleneck
Because these four steps happened in one unbroken chain of execution, the browser was effectively "locked" until the very last component in the tree was processed. If your component tree was large, this led to two major issues:

"Jank" and Dropped Frames: To maintain a smooth 60fps, a browser has about 16.6ms to paint a frame. If reconciliation took 30ms, the browser would skip a frame, leading to visible stuttering or "jank."
Delayed User Interactions: If a user typed into an input field while React was busy reconciling a large list, the keystroke wouldn't appear on the screen until the entire tree was finished.

The Realization
React engineers realized that Simultaneous Diffing and Patching was a dead end for complex, highly interactive applications. To move forward, they needed to achieve two things:

Decouple the "Math" (Diffing) from the "Writing" (Patching).
Enable Pausing: The ability to stop the "Math" if the user does something more important.

This realization set the stage for the most ambitious rewrite in React's history: Fiber. In Part 2, we will dive deep into how Fiber completely re-engineered the internals of React to make the web feel more fluid than ever before.