React 19.3 vai além das animações: revise os contratos da sua interface gerada por IA

Uma IA entrega uma tela em React com aparência de pronta. A navegação local é rápida, a transição ficou bonita e o diff parece limpo. Aí alguém abre uma rota diretamente: o HTML inicial não combina com o estado do cliente. Em um celular mais lento, a animação interrompe o foco. Em outro fluxo, conteúdo vindo do CMS chega ao DOM sem uma política clara.

O problema não é presumir que IA escreve frontend ruim. É aceitar velocidade de geração como evidência de comportamento correto. Quando o código aparece em minutos, várias decisões que antes surgiam durante a implementação ficam comprimidas em uma resposta convincente.

O React 19.3 oferece uma boa oportunidade para reabrir essas decisões. View Transitions e Fragment Refs passaram a estáveis, o React DOM ganhou browser() para conteúdo que só pode ser renderizado no cliente e suporte a Trusted Types, enquanto Server Components agora podem renderizar Context diretamente.

Isso não pede uma migração que ligue tudo de uma vez. Pede uma rota piloto, contratos pequenos e observação no navegador.

A release não é o checklist; o seu produto é

Antes de alterar o código, escolha uma rota real. Pode ser a página de detalhes de um projeto, um checkout secundário ou um painel interno. O importante é que ela tenha comportamentos suficientes para revelar as fronteiras da aplicação sem colocar o fluxo mais crítico em risco.

Registre um baseline dessa rota:

HTML recebido no acesso direto;
estado depois da hidratação;
erros e avisos no console;
navegação por teclado e posição do foco;
capturas nos viewports que o produto suporta;
métricas e testes que a equipe já acompanha.

Esse material não precisa virar um relatório enorme. Ele só precisa permitir a comparação entre antes e depois. Sem baseline, uma mudança visualmente agradável pode apagar uma regressão que já existia ou introduzir outra sem deixar um rastro claro.

Também vale anotar os fluxos que importam para a rota: acesso por URL, refresh, navegação interna, conteúdo dinâmico, estado vazio, erro, loading e conexão limitada. É esse conjunto, e não o anúncio da versão, que define o trabalho de migração.

Marque onde o servidor termina e o navegador começa

Interfaces geradas com ajuda de IA costumam misturar rápido demais dados do servidor, estado hidratado e APIs do navegador. Isso pode funcionar durante a navegação interna e falhar no primeiro acesso, quando ainda não existem window, viewport ou preferências calculadas no cliente.

O browser() do React DOM entra justamente no caso de conteúdo que só pode ser renderizado no navegador. Antes de usá-lo, porém, faça um inventário simples:

qual componente depende de uma capacidade exclusiva do cliente;
o que o servidor consegue renderizar sem inventar informação;
qual estado o usuário vê antes da hidratação;
o que deve permanecer igual após a primeira interação.

A fronteira restrita ao cliente é útil quando a dependência do navegador é legítima. Ela não deve esconder uma divergência de hidratação que poderia ser corrigida. Se servidor e cliente deveriam produzir a mesma estrutura, empurrar o trecho inteiro para o navegador só troca uma falha visível por mais trabalho no cliente.

Teste pelo menos acesso direto, refresh e navegação interna. Os três caminhos podem chegar à mesma tela por estados diferentes, e é aí que contratos implícitos aparecem.

Trusted Types precisa virar política operacional

O suporte a Trusted Types no React DOM não transforma conteúdo dinâmico em conteúdo seguro por padrão. Ele cria uma base melhor para controlar como certos valores chegam ao DOM, mas a aplicação ainda precisa decidir o que considera confiável e onde a política será aplicada.

Comece localizando os pontos que recebem HTML, Markdown processado, conteúdo de CMS, plugins ou qualquer saída transformada antes da renderização. Para cada um, registre a origem, a sanitização existente e a escrita final no DOM. Dependências antigas merecem atenção especial porque podem usar caminhos que não respeitam a política nova.

Ative o controle primeiro em uma superfície estreita e observe as violações. Um painel interno com poucos tipos de conteúdo é um piloto melhor do que o produto inteiro. Se algo quebrar, a equipe consegue identificar se o problema está na origem dos dados, na transformação ou na integração com uma biblioteca.

Trusted Types ajuda a tornar a fronteira auditável. Não elimina XSS, não corrige uma sanitização fraca e não substitui revisão das entradas aceitas pelo produto.

Transição é comportamento, não acabamento

View Transitions estável pode facilitar experiências com mais continuidade visual. Só que uma transição não existe apenas para ficar bonita no vídeo de demonstração. Ela acontece enquanto o usuário navega, digita, muda de ideia e, às vezes, pede menos movimento ao sistema.

Teste a rota com navegação normal, cliques rápidos e atualização de estado durante a transição. Depois passe pelo teclado e confira onde o foco termina. Respeite a preferência por movimento reduzido e veja qual experiência sobra quando a transição não acontece.

Fragment Refs também merece uma adoção guiada pelo contrato, não pela curiosidade. Antes de mudar referências, escreva qual estrutura a aplicação espera preservar e qual parte do comportamento depende dela. Se a árvore visual mudar, o time precisa saber se a referência ainda representa a mesma unidade lógica.

Não vale remodelar a árvore de componentes inteira para experimentar duas capacidades na mesma pull request. Mudanças menores deixam a regressão mais fácil de explicar e de reverter.

Context no servidor pede responsabilidade clara

A possibilidade de renderizar Context diretamente em Server Components simplifica alguns fluxos, mas também pode esconder dependências amplas se o time mover tudo de uma vez.

Escolha um contexto pequeno e responda quatro perguntas antes da migração:

Quem fornece esse valor?
Quais componentes o consomem?
Em qual fronteira ele deixa de existir ou muda de forma?
O que deve continuar idêntico para o usuário?

Mova esse caso sem aproveitar a mesma tarefa para reorganizar cache, layout e carregamento de dados. Quando várias fronteiras mudam juntas, uma responsabilidade mal definida parece problema de renderização, e o diagnóstico fica mais caro.

Use casos representativos, não só a tela feliz

Uma UI gerada por IA precisa ser exercitada com estados próximos do produto. Inclua resposta em streaming, dados parciais, lista vazia, erro recuperável, ação destrutiva com confirmação e conteúdo maior do que o exemplo usado no prompt.

Se a equipe precisa ampliar esse repertório, os recursos de Generative UI em português reúnem SDKs, frameworks, projetos e exemplos que podem servir de referência para novas fixtures. Esse catálogo ajuda a encontrar formatos diferentes de interface; ele não comprova compatibilidade com React 19.3 nem substitui os testes da aplicação.

Uma fixture boa descreve entrada, estado esperado e limite relevante. “Renderizar um card criado pela IA” é vago. “Receber dados parciais em streaming, manter a ação principal desabilitada e preservar o foco quando o conteúdo completar” já oferece algo verificável.

Faça o agente enxergar o runtime

Revisar o diff continua necessário, mas o diff não mostra hidratação, foco, movimento ou comportamento sob CPU limitada. Se um agente participa da implementação, dê a ele um caminho controlado para observar o navegador.

O Chrome DevTools for agents 1.0 permite conectar agentes ao Chrome por MCP, CLI e skills. O fluxo também pode executar Lighthouse e emular dispositivo, rede e CPU. Isso é útil para repetir uma matriz curta, desde que cada execução produza um registro que outra pessoa consiga conferir.

Uma matriz inicial pode caber em quatro cenários:

Cenário	O que observar
Desktop, acesso direto	HTML inicial, hidratação e console
Mobile, navegação interna	layout, foco e interação principal
CPU e rede limitadas	loading, transição interrompida e resposta a cliques
Jornada por teclado	ordem de foco, confirmação e retorno após atualização

Para cada linha, salve a rota, o commit, a configuração usada, o resultado esperado e o observado. Screenshot, trace, assertion e métrica respondem perguntas diferentes. Uma imagem bonita não prova que o teclado funcionou; console limpo não prova que a experiência ficou acessível.

O agente pode acelerar a coleta dessas evidências. A decisão sobre experiência aceitável e risco continua com o time.

Um rollout que cabe em uma tarde

A primeira rodada pode ser pequena:

escolha uma rota não crítica e salve o baseline;
selecione um contrato, como a fronteira entre servidor e navegador;
defina o comportamento esperado e o critério de reversão;
aplique a menor mudança possível;
rode os testes determinísticos e a matriz no navegador;
compare as evidências e reverta se o resultado não puder ser explicado.

Só depois repita o processo com Trusted Types, transições, Fragment Refs ou Context. A sequência pode parecer mais lenta do que pedir à IA uma migração completa. Na prática, ela reduz o tempo gasto tentando descobrir qual das cinco mudanças causou uma regressão.

React 19.3 fornece capacidades novas; o produto ainda precisa declarar seus limites. Use a IA para acelerar a alteração e a investigação, mas encerre a tarefa apenas quando outra pessoa conseguir reproduzir o comportamento observado. Para começar, escolha uma rota hoje e transforme um único detalhe implícito em um contrato testável.