What is React Fiber?

The short answer

React Fiber is the reimplementation of React's core reconciliation algorithm, introduced in React 16. It replaced the old "stack reconciler" with a new architecture that can pause rendering work, split it into chunks, assign priorities to different updates, and resume where it left off. This is the foundation that makes concurrent features like Suspense, transitions, and useTransition possible.

The problem Fiber solved

To understand Fiber, you need to understand what came before it.

The original React reconciler (sometimes called the "stack reconciler") worked like a recursive function call. When state changed, React would start at the top of the component tree and recursively render everything that needed updating. The critical limitation was that this process was synchronous and uninterruptible. Once React started reconciling, it couldn't stop until the entire tree was processed.

For small apps, this wasn't a problem. But for large component trees, this synchronous rendering could block the main thread for tens or even hundreds of milliseconds. During that time, the browser couldn't respond to user input, run animations, or do anything else. The result was janky, unresponsive UIs — exactly the kind of experience React was supposed to prevent.

You might wonder: why couldn't the old reconciler just stop halfway through? Because it used the JavaScript call stack directly. Each component render was a function call on the stack, and you can't pause a JavaScript call stack mid-execution and come back to it later.

How Fiber works

Fiber's key insight was to move the work off the call stack and into a data structure that React controls. Instead of relying on recursive function calls, Fiber represents each unit of work as a JavaScript object — a fiber node. Each component in your tree has a corresponding fiber.

These fiber nodes form a linked list (not a traditional tree traversal using the call stack), which means React can process one fiber at a time and then decide: should I continue to the next one, or should I yield control back to the browser?

Here's the conceptual flow:

1. An update is triggered (state change, prop change)
2. React starts processing fiber nodes one by one
3. After each unit of work, React checks: is there higher-priority work waiting? Has too much time passed?
4. If yes, React pauses the current work and lets the browser handle animations, user input, or paint
5. When the browser is idle again, React resumes from where it left off
6. Once all the work is complete, React commits the changes to the DOM in a single, synchronous batch

This two-phase approach is important. The render phase (figuring out what changed) can be interrupted. The commit phase (actually updating the DOM) runs synchronously so the user never sees a half-updated UI.

The fiber tree

Each fiber node is a plain JavaScript object that holds information about a component: its type, props, state, and pointers to other fibers. The structure uses three key relationships:

• child — points to the first child fiber
• sibling — points to the next sibling
• return — points back to the parent

This linked-list structure lets React traverse the tree iteratively instead of recursively. And because each step is just "move to the next pointer," React can stop at any fiber, save its position, and resume later. Try doing that with a recursive call stack.

React actually maintains two fiber trees at once: the current tree (what's on screen) and the work-in-progress tree (what's being calculated). When the work-in-progress tree is complete, React swaps them. This "double buffering" technique ensures the on-screen UI is always consistent.

Priority and scheduling

Not all updates are equally urgent. A user typing in a search field needs immediate feedback. A data fetch completing in the background can wait a moment. The old synchronous reconciler treated every update the same. Fiber introduced the concept of priority levels.

Different types of updates get different priorities:

• Immediate — synchronous, like the old behavior. Used for critical updates that can't wait.
• User-blocking — input events, clicks. These need to be processed quickly.
• Normal — data fetches, state updates from non-urgent sources.
• Low — analytics, logging, off-screen updates.
• Idle — work that can happen whenever the browser is truly idle.

React's scheduler determines which work to do first. If a low-priority render is in progress and a high-priority update comes in (the user clicked something), React can interrupt the low-priority work, handle the click, and then resume the background work.

What Fiber enables

Fiber itself isn't a feature you interact with directly. It's the architecture that makes a whole family of features possible:

• Concurrent rendering — multiple versions of the UI can be "in progress" at the same time, letting React keep the current UI responsive while preparing the next one in the background.
• Suspense — when a component suspends (throws a promise), React can pause that subtree and show a fallback, then resume when the data is ready.
• Transitions — useTransition and startTransition mark updates as non-urgent, so React can keep the UI responsive while processing them.
• Automatic batching — Fiber's architecture made it natural to batch state updates across async boundaries, not just inside event handlers.

None of these would be possible with the old synchronous, all-or-nothing reconciler.

Keeping it in perspective

Fiber is an implementation detail of React's internals. As an application developer, you don't interact with fiber nodes directly. You don't create them, configure them, or think about them in your day-to-day code.

What matters is understanding the mental model: React can break rendering into chunks, prioritize work, and keep the UI responsive even during heavy updates. When you use useTransition to keep a list filterable while it re-renders thousands of items, Fiber is the reason that works.

Why interviewers ask this

Fiber questions test your understanding of React's architecture beyond the API surface. Interviewers aren't expecting you to explain the linked-list traversal algorithm — they want to see that you understand why React needed this rewrite (the synchronous reconciler was a bottleneck), what it enables (concurrent features, priority scheduling), and how it affects the way you think about rendering in React. It shows you've gone deeper than tutorials and understand the system you're building on.