React 19.3 bringt browser() API für reines Client-Rendering

The problem it targets is familiar to anyone doing SSR. Components that read localStorage, window, or the device timezone cannot produce meaningful HTML on the server, and the existing workarounds were awkward. Developers either flipped a mounted flag inside an effect or guarded rendering with typeof window!== 'undefined', a pattern that causes hydration mismatches the moment the server and first client render disagree.

import { use } from 'react'; import { browser } from 'react-dom'; function LocalTime() { use(browser()); return <p>{new Intl.DateTimeFormat().resolvedOptions().timeZone}</p>; } During server rendering, use(browser()) stops the component and leaves the nearest Suspense boundary's fallback in the HTML. In the browser it returns undefined, so the component renders as normal after hydration. It must be called from a Client Component and sit inside a Suspense boundary, or the server render fails.

Because use() can live behind a condition, a component can defer only when it has to, for example a data hook that renders on the server when a loader supplies initialData and opts out otherwise. React also adds an onBrowserBailout callback and an optional reason argument so teams can report exactly where server rendering was skipped.

The change first landed as a React core PR that This Week in React described as "eliminating hacky server error-suppression workarounds". In the docs issue tracking the feature, one contributor wrote they were "very excited about the browser() api because it solves the client-only component problem in a much cleaner way than the previous ways". Writing about the release, one developer called the conditional data-fetching version "the cleanest solution to the 'should this fetch on the server or not' question I've seen".

The approach also narrows the gap with framework-specific escape hatches. Next.js users have long reached for dynamic(() => import('./C'), { ssr: false }) via next/dynamic, and Astro exposes a client:only directive, but both are tied to their bundlers. browser() moves the capability into React itself, so it works with any SSR setup rather than a single framework.

Upgrading is a standard bump to react@19.3 and react-dom@19.3, following the React 19 upgrade guide, though the use reference still flags browser() as Canary only, so confirm your release channel before depending on it in production.