React 18

React 18 introduced the concurrent renderer through the client root APIs createRoot and hydrateRoot. It added automatic batching for more update sources, transitions through startTransition and useTransition, useDeferredValue, useId, useSyncExternalStore, and useInsertionEffect. Its server-rendering work added streaming APIs and Suspense-aware selective hydration. Existing applications could continue to use legacy ReactDOM.render or hydrate, but those roots do not enable the new concurrent behavior and were a transitional compatibility path. No end-of-life has been declared for React 18.

React 18 has a stated active-support boundary, and that support boundary has passed. A team remaining on it should not plan on routine maintenance work, compatibility changes, or fixes being made for this line. The immediate technical risk is less about concurrent rendering itself and more about ecosystem drift: libraries, tooling, framework integrations, and browser-facing dependencies may increasingly test and publish against newer React behavior. React 18 also lacks newer React APIs and platform integrations, while code that still relies on legacy roots will face a larger migration because those APIs are removed in newer React releases. Security and production issues may require the team to diagnose, mitigate, or upgrade rather than wait for a React 18 update.

First, move to the latest available React 18 patch within the line and establish a representative test baseline for rendering, hydration, Suspense, error handling, and third-party components. Inventory every use of ReactDOM.render and ReactDOM.hydrate, then replace them with createRoot and hydrateRoot before a major-version upgrade; test under StrictMode because it can expose unsafe effects and lifecycle assumptions. Check all React-adjacent packages, including the framework, router, state libraries, testing utilities, component libraries, and type packages, for peer-dependency and compatibility declarations for the target React release. Run browser and server-rendering tests against the newer React version, with particular attention to hydration mismatches, refs, deprecated APIs, and code that depends on rendering timing. Treat the passed support boundary as a reason to schedule the upgrade as planned maintenance rather than waiting for an incident.