React's browser() API pushes the SSR opt-out down into the component

The fallback shown for a browser-only component is inherited, not chosen by the component itself. On the server, `use(browser())` stops rendering that component and leaves the closest Suspense boundary's fallback in its place ^[3]. The component does not choose what the user sees; the nearest boundary does, and it was chosen for streaming reasons months ago. A boundary wrapped around a whole sidebar turns the whole sidebar into a placeholder in the first paint. A boundary wrapped tight around the browser-only leaf ships everything else. Boundary granularity is now the blast radius of the opt-out as well as a streaming knob.

The requirement is hard, not advisory. Without a boundary above it, the server render fails ^[4]. In a React Server Components app the call has to come from a Client Component, not a Server Component ^[5]. That is the adoption cost per component: you need a boundary in place for each one, and no global find-and-replace covers it.

The `reason` argument reads like a minor ergonomic touch, but it functions as a cost model. A string or a function explains the bailout, and its value becomes the `cause` of the `Error` passed to `onBrowserBailout` ^[7]. React calls a reason function each time a server renderer encounters the value returned by `browser`, and never calls it in the browser ^[8]. React re-evaluates the reason function on every encounter instead of caching it, so a hoisted `browser(() => new Error(...))` on a hot path pays that cost each time. The docs recommend the function form specifically when creating the reason is expensive ^[8].

Reporting is a separate channel. You pass `onBrowserBailout` to the server renderer, and it receives an `Error` plus an `errorInfo` ^[10]. When React leaves a fallback for the browser it does not call the server renderer's `onError`, and it does not call `hydrateRoot`'s `onRecoverableError` ^[11]. A page that quietly stopped server rendering half its content will look clean in an error dashboard until that callback exists.

The design decision I would actually build on is that the call can be conditional or live inside a custom Hook ^[13]. The docs' `useBrowserQuery` example bails out only when `options.initialData` is undefined, so the server keeps the fallback and the browser either fetches or reads from the query cache ^[13]. Browser-only stops being a static property of a component and becomes a runtime question about the data you were handed, which is the shape data-fetching wrappers already have.

Now the transfer test. In the `SavedDraft` example the initial HTML contains the loading fallback, and the draft from `localStorage` appears after hydration ^[14]. That is an improvement in your app only if your current path already shipped a placeholder. The docs name three patterns this replaces ^[15]: a `typeof window` check, an Effect that sets mounted state, and a framework option that disables server rendering ^[9]. If you use the mounted-Effect version today, the pixels are unchanged and the delta is one deleted branch plus a reason string you can log. If you currently server-render a degraded but real version of the component, you are trading HTML for a fallback, and the cost shows up in the content users see, not in how clean the code looks.

One failure mode deserves flagging. Calling `browser()` on its own has no effect, and the returned value must be passed to `use` rather than thrown ^[6]. The docs spelling out "do not throw it" is a reasonable guess about where a decade of Suspense habits sends people. A half-finished migration therefore fails silently: the component keeps server rendering, and nothing reports it, because the reporting hook only fires on an actual bailout ^[11].