Why can React now interrupt rendering?

ReactMiddle~3 min read

1. What it was like before (React <= 17)

Rendering was synchronous and blocking.
When setState() was called, React recursively walked the entire subtree and computed a new Virtual DOM.
While that happened, the JS thread was fully busy - the browser could not:
- handle clicks or scrolling,
- run animations,
- react to user input.

In other words, rendering = one long "uninterruptible" operation.

2. Fiber - the foundation for interruptible rendering

Since React 16, the entire component tree is stored as linked Fiber nodes. Each Fiber is a unit of work, containing:

javascript

type FiberNode = {
  type: ComponentType;
  props: any;
  stateNode: any;
  child: FiberNode | null;
  sibling: FiberNode | null;
  return: FiberNode | null;
  lanes: PriorityBits;
  ...
}

React can process these nodes one at a time, instead of the whole tree at once. If, in between, the browser says:

"Hey, I have a user event!" React stops walking and yields control back to the thread.

3. Concurrent Rendering (React 18)

React turned into a scheduler. It tracks the priority of different tasks:

Priority	Example	Behavior
High	click, typing text	Run immediately, interrupting the current render
Medium	a transition	Run once the thread frees up
Low	filtering a list, loading data	Can be done "in the background"

When more important work comes in, React:

saves the context of the current Fiber tree;
stops the current render (render phase);
handles the urgent update;
if needed, resumes the previous render from where it stopped.

4. What this gives you

Before	After
Rendering blocks the UI	Rendering can be paused
All updates are equal	There are priorities
A render cannot be canceled	It can be canceled and recomputed
Effects run once	Effects are guaranteed to run only after the commit phase
The user waits	The UI stays responsive

5. An intuitive example

javascript

startTransition(() => {
  setHeavyList(generateBigList()); // a low-priority task
});

If the user clicks a button or keeps typing during this:

React pauses the list update,
quickly handles the click (an urgent-type setState),
then resumes the background render.

The UI does not freeze, because React can interrupt and defer heavy updates.

6. How this relates to the lifecycle

The render phase can now be interruptible and repeated. A component may "render" several times before reaching the commit.
The commit phase stays atomic and synchronous - changes are applied to the DOM only once React is certain the render is finished.
Effects (useEffect, useLayoutEffect) run only after the commit - that is, after all possible cancellations and pauses.

7. The key technical reasons React can now interrupt rendering

Fiber = units of work -> React can process them step by step.
Scheduler API (cooperative scheduling) -> React knows how much time has passed and can yield the thread to the browser.
Priorities (lanes) -> updates of different types are stored in "lanes" with different priorities.
Concurrent Mode -> React is not required to commit changes right away, it can defer them.
Suspense and Transitions -> let you defer "heavy" renders without blocking the UI.

8. Visually

javascript

Render phase (can be paused)
 |-- Fiber A
 |-- Fiber B  <- React can interrupt here
 |      ^ the user clicked -> handle the urgent update
 `-- Fiber C (finish later)

Commit phase (always synchronous)
 `-- Apply the changes to the DOM

9. Summary

React can interrupt rendering because it is now a cooperative scheduler, not a linear function call.

This became possible thanks to:

the Fiber architecture (splitting work into small steps),

Concurrent Rendering (priorities and asynchrony),

the Scheduler API (yielding to the browser).

As a result:

the UI stays responsive,
a render can be paused, canceled, and resumed,
the lifecycle became safer and more precise in the commit phase.

Short Answer

Interview ready

Premium

A concise answer to help you respond confidently on this topic during an interview.