CreateRoot

The React 18 root API used to mount an application into the DOM. It replaces ReactDOM.render and enables the newer rendering model, including automatic batching and concurrent features. For migration work, it is the point where teams should revalidate assumptions about update timing, state visibility, and test behavior.

What CreateRoot changes in a React 18 application

CreateRoot changes the root rendering model, so migration is not just a syntax swap. It affects how React schedules updates, batches state changes, and treats rendering work under concurrent features, which means existing assumptions about timing can break.

For teams moving from ReactDOM.render, the practical question is whether components, effects, and tests still behave the same way when the app is mounted through the newer root API. That is why migration work should focus on user-visible behavior, not only on compile-time success.

Why the root API matters during migration

The root API defines how the application enters the React runtime. In React 18, that entry point is tied to the newer rendering model, including automatic batching and support for concurrent rendering behavior, so the mount step becomes a control point for the whole app.

This matters most when code depends on immediate state visibility, tightly ordered updates, or rendering side effects that were previously masked by older behavior. Even if the UI still loads, subtle timing changes can alter how data flows through components and how quickly the interface reflects updates.

Common compatibility issues

The most common problems are not catastrophic failures, but behavior shifts. Code that reads state immediately after an update, logic that assumes one render per event, and tests that depend on legacy flush timing can all produce different results under CreateRoot.

Migration often exposes assumptions that were never guaranteed by the framework. Teams should expect to revisit test helpers, effect timing, and any code that relies on synchronous rendering side effects, especially in complex stateful views.

If you are validating migration impact, React’s official createRoot reference is the primary source for the API’s behavior, and the legacy ReactDOM documentation helps explain what changed from the older entry point.

How to think about CreateRoot in practice

Use CreateRoot as a signal to re-check application assumptions rather than as a purely mechanical upgrade. The mount call itself is simple, but the runtime consequences extend into scheduling, testing, and user experience, so the migration should be validated with realistic interactions.

For practitioners, the useful mindset is to treat the root change as an opportunity to confirm that the application remains correct when React is allowed to optimize rendering more aggressively. That includes checking for hidden dependencies on old update ordering and making sure tests assert outcomes instead of implementation timing.

For broader implementation guidance, the React documentation remains the most direct reference for the modern rendering model and related APIs.