React 19.3 cria API browser() para marcar componentes que só existem no cliente

O que mudou

O React↳React37 conteúdos7 erros com React moderno que só aparecem em produção; e como evitarDev (Back & Front) · abr 2026React Native 0.76: o futuro do desenvolvimento mobileDev (Back & Front) · out 2024Simplificando componentes com React HooksDev (Back & Front) · mar 2019Ver tudo em Dev (Back & Front) → 19.3 foi publicado no npm em 9 de setembro de 2026. Ao lado de recursos já estáveis como View Transitions e Fragment Refs, a versão traz uma peça menor, mas que resolve um incômodo antigo de quem faz SSR: a browser(), uma nova API do pacote react-dom. Ela formaliza algo que todo time já fez na marra, declarar que um componente só faz sentido depois que o JavaScript carrega no navegador.

A API ainda está no canal Canary, não na build estável que a maioria instala em produção. Quem documentou o recurso foi Aurora Scharff, e a referência já está publicada, mas confirmar o canal de release antes de depender dela em produção é parte do pacote.

O problema que ela resolve

Quem já fez SSR conhece a cena: um componente precisa ler localStorage, window ou o fuso horário do dispositivo, e nenhuma dessas informações existe no servidor. A saída tradicional era um de dois hacks. Ou um useEffect com uma flag mounted, ou uma checagem typeof window !== 'undefined' espalhada pelo componente.

Os dois funcionam, mas os dois têm o mesmo efeito colateral: o HTML que o servidor manda é diferente do que o React calcula no primeiro render do cliente, e isso dispara um erro de hidratação. É o tipo de bug que aparece no console em produção, raramente em desenvolvimento, e que historicamente obrigava a suprimir o aviso com gambiarras adicionais em vez de resolver a causa.

Como o browser() funciona na prática

A API se usa com o hook use(), que já existia para lidar com promises e contexto. Chamar use(browser()) dentro de um Client Component faz o componente suspender durante a renderização no servidor:

import { use } from 'react';
import { browser } from 'react-dom';

function LocalTime() {
 use(browser());
 return <p>{new Intl.DateTimeFormat().resolvedOptions().timeZone}</p>;
}

No servidor, esse use(browser()) interrompe o componente e deixa o HTML com o fallback do Suspense boundary mais próximo. No navegador, a mesma chamada retorna undefined, e o componente renderiza normalmente depois da hidratação. Duas regras são obrigatórias: o componente precisa ser um Client Component e precisa estar dentro de um Suspense boundary, senão a renderização no servidor falha.

Como use() pode ficar atrás de uma condição, dá para decidir a renderização caso a caso. Um hook de dados, por exemplo, pode renderizar no servidor quando um loader já forneceu initialData e só pular para o cliente quando não forneceu. O React também adiciona um callback onBrowserBailout, com um argumento opcional reason, para o time registrar exatamente onde e por que a renderização no servidor foi pulada.

O que a comunidade já disse sobre isso

A mudança nasceu como um PR no núcleo do React. O boletim This Week in React descreveu o efeito prático da seguinte forma:

Eliminando workarounds improvisados de supressão de erro no servidor.

Eliminating hacky server error-suppression workarounds.Newsletter This Week in React

No issue da documentação que acompanhou o recurso, um colaborador resumiu o ganho:

Estou muito animado com a API browser() porque ela resolve o problema do componente client-only de um jeito bem mais limpo do que as formas anteriores.

Very excited about the browser() api because it solves the client-only component problem in a much cleaner way than the previous ways.Colaborador, issue de documentação do React

Um desenvolvedor, ao comentar o lançamento, foi na mesma direção ao falar da variante condicional com dados:

A solução mais limpa que já vi para a pergunta "isso deveria buscar dados no servidor ou não".

The cleanest solution to the "should this fetch on the server or not" question I've seen.Desenvolvedor, em post sobre o lançamento do React 19.3

Como isso se compara ao que já existia nos frameworks

Quem usa Next.js já tinha uma saída de emergência parecida: dynamic(() => import('./C'), { ssr: false }), via next/dynamic. O Astro tem a diretiva client:only. Os dois funcionam, mas os dois são amarrados ao bundler de cada framework, o que trava quem monta uma stack SSR fora desses ecossistemas, ou quem mantém mais de um framework no mesmo portfólio de projetos.

A diferença central é onde a decisão mora. Com browser(), ela fica no React, portanto funciona em qualquer configuração de SSR que o time já tenha montado na mão, sem depender de um bundler específico assinar o contrato.

O que isso muda para arquitetura de app no Brasil

Times brasileiros que mantêm SSR customizado, seja com Vite mais um servidor Express, seja com uma integração própria de React em cima de outro stack, ganham uma saída que não depende de reimplementar o que Next.js ou Remix já resolveram internamente. Isso importa especialmente para quem roda React fora dos frameworks full-stack mais populares, caso comum em backends corporativos que optaram por montar o próprio pipeline de renderização.

Em resumo: antes de adotar, vale medir onde hoje o projeto já usa typeof window !== 'undefined' ou um useEffect com flag de montagem. Esses pontos são candidatos diretos à migração, mas a migração em produção só faz sentido quando browser() sair do Canary, porque a API ainda pode mudar de formato até a estabilização.

O que fica em aberto

A documentação oficial ainda trata browser() como Canary only, sem data pública de estabilização. Isso significa que times que decidirem adotar antes da versão estável precisam monitorar os changelogs do React para mudanças de assinatura, e evitar publicar essa dependência em bibliotecas internas compartilhadas enquanto o contrato não travar. A atualização de versão em si é simples, um bump padrão para react@19.3 e react-dom@19.3 seguindo o guia de upgrade do React 19, mas isso atualiza o framework, não libera o uso em produção da API ainda em teste.

Fonte: InfoQ