Suggest an editImprove this articleRefine the answer for “Why can React now interrupt rendering?”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)React can interrupt rendering because it is now a **cooperative scheduler**, not a linear function call. **Key point:** this became possible thanks to the Fiber architecture (splitting work into small steps), Concurrent Rendering (priorities and asynchrony), and the Scheduler API (yielding to the browser).Shown above the full answer for quick recall.Answer (EN)Image## 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: 1. **saves the context** of the current Fiber tree; 2. **stops** the current render (render phase); 3. **handles the urgent update**; 4. 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 1. **Fiber = units of work** -> React can process them step by step. 2. **Scheduler API (cooperative scheduling)** -> React knows how much time has passed and can yield the thread to the browser. 3. **Priorities (lanes)** -> updates of different types are stored in "lanes" with different priorities. 4. **Concurrent Mode** -> React is not required to commit changes right away, it can defer them. 5. **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.For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.