Concurrent Rendering and Interruptible Rendering

Concurrent rendering lets React work on rendering without treating that work as an immediate commitment to the DOM. React can pause, resume, restart, or discard unfinished rendering work before it commits the result.

In React, rendering calculates what the UI should look like from the current props and state. With concurrent rendering, that calculation is not necessarily completed in one uninterrupted pass. React can yield so other work can be handled first, then continue rendering later.

The important boundary is the commit phase. Rendering work can be interrupted or abandoned before commit, but once React commits a result, the corresponding DOM mutations and effects follow the normal commit behavior. This means render logic must be safe to execute more than once.

Scheduling priorities determine which updates React should work on first. APIs such as `startTransition` let an application mark an update as non-urgent, allowing more urgent interactions to receive attention while React works on the transition.

Concurrent rendering does not mean that JavaScript rendering code literally runs on another thread. React is still executing JavaScript on the main thread in typical browser applications; concurrency refers to React's ability to schedule and manage rendering work rather than blocking on one render attempt.

Key points

• Rendering work can be paused before it is committed.
• Unfinished rendering can be abandoned and restarted.
• The commit phase is distinct from the render phase.
• Render code should remain pure because React may execute it multiple times.
• `startTransition` marks updates as non-urgent work.

Interview questions

What does interruptible rendering mean in React?

It means React does not have to finish every rendering calculation in one uninterrupted pass. React can pause rendering, handle higher-priority work, and later continue or restart the calculation. If the work becomes obsolete, React can discard it instead of committing it. Only the selected completed result is committed to the UI.

Why does concurrent rendering require render logic to be pure?

React may start rendering a component and then render it again before committing either result. If the render function changes external state, performs network requests, or causes other side effects, those actions could happen even when that render attempt is later discarded. Pure rendering avoids observable effects from speculative work. Side effects should instead be placed in appropriate mechanisms such as event handlers or effects.

What is the difference between the render phase and the commit phase?

The render phase determines what the next UI should be based on component inputs and state. In concurrent rendering, that work can be interrupted, repeated, or abandoned. The commit phase takes the selected result and applies the necessary changes to the host environment, such as the DOM. This separation allows React to treat rendering as schedulable work while keeping the final UI update coordinated.

How does `startTransition` relate to concurrent rendering?

`startTransition` lets React know that updates triggered inside the callback are non-urgent. React can then keep more urgent interactions responsive while working on the transition. The transition work may be interrupted if higher-priority work arrives. It does not make the update run on another thread or guarantee that rendering will always be interrupted.

What bugs can appear if a component performs side effects during render?

A side effect in render can run even when React later abandons that render attempt. Repeated rendering can also cause the effect to happen multiple times, producing duplicated requests, mutations, subscriptions, or other external changes. Concurrent rendering therefore makes render purity especially important. External effects should be coordinated through event handlers or lifecycle mechanisms designed for side effects.