O React 19.3 chegou com duas APIs que deixam de ser experimentais: ViewTransition e refs em Fragment. As duas lidam com um problema parecido — coordenar uma interface que não cabe bem em um único elemento do DOM — mas atacam lados diferentes. A primeira organiza transições visuais; a segunda permite observar e manipular um conjunto de nós sem adicionar uma div só para servir de apoio.
ViewTransition entra no conjunto estável
O componente <ViewTransition> integra a View Transition API ao ciclo de renderização do React. Em vez de o aplicativo decidir manualmente quando chamar document.startViewTransition(), o React identifica atualizações relevantes, atribui nomes às regiões e escolhe o tipo de transição: entrada, saída, atualização ou compartilhamento.
import { ViewTransition } from 'react';
export function ProductCard({ product }) {
return (
<ViewTransition name={`product-${product.id}`}>
<img src={product.image} alt="" />
</ViewTransition>
);
}
Sem CSS adicional, o navegador usa um crossfade. O valor aparece quando o time define transições específicas para regiões importantes sem espalhar controle imperativo pelo roteador e pelos componentes. Ainda é uma API de DOM: não tente transportar o componente para React Native como se ele fosse uma abstração universal.
Fragment refs sem wrapper artificial
Refs em Fragment retornam um FragmentInstance capaz de operar sobre os filhos do fragmento. A API reúne métodos para eventos, foco, observação de interseção ou redimensionamento, retângulos e rolagem. Isso é útil em listas compostas, grupos de campos e componentes de acessibilidade nos quais inserir um contêiner mudaria layout ou semântica.
import { Fragment, useRef } from 'react';
function Fields() {
const groupRef = useRef(null);
return (
<Fragment ref={groupRef}>
<label htmlFor="name">Nome</label>
<input id="name" />
</Fragment>
);
}
Há uma pegadinha sintática: a ref exige o Fragment explícito. A forma curta <>...</> não recebe atributos. E, como toda ref, esse recurso não deve substituir fluxo declarativo por manipulação indiscriminada.
SSR consegue esperar pelo navegador
Outra adição é browser(), exportada por react-dom. Ao usar use(browser()), o componente suspende durante a renderização no servidor, mas continua normalmente no cliente. Isso permite declarar que uma região só faz sentido no navegador e fornecer um fallback de Suspense, sem criar uma Promise artesanal que nunca resolve no servidor.
É uma ferramenta cirúrgica. Se a página inteira depender dela, você volta a entregar pouco HTML útil. O melhor encaixe está em widgets baseados em APIs exclusivamente client-side, cercados por conteúdo que ainda pode ser renderizado no servidor.
Trusted Types e Server Components
O React 19.3 deixa de converter objetos Trusted Types em strings antes de passá-los aos sinks correspondentes do DOM. Para aplicações que aplicam uma política de Trusted Types contra DOM XSS, isso preserva a garantia fornecida pelo navegador em vez de destruir o tipo seguro no caminho.
Em React Server Components, um contexto também pode ser renderizado diretamente. É uma melhoria de composição, não um sinal para transportar estado arbitrário do cliente para o servidor. As fronteiras de serialização e execução continuam existindo.
Como eu faria a atualização
- Atualizaria React e React DOM juntos e rodaria a suíte antes de adotar APIs novas.
- Escolheria uma única navegação para experimentar ViewTransition, com fallback visual aceitável.
- Removeria wrappers apenas onde Fragment refs melhoram de fato a semântica.
- Revisaria integrações com HTML confiável se o projeto usa Content Security Policy e Trusted Types.
Não é uma versão que exige reescrever a aplicação. É uma atualização que amadurece peças específicas e permite apagar algumas gambiarras. O ganho aparece quando a adoção começa por problemas reais, não por uma busca ansiosa por lugares onde encaixar a API da semana.

