React Compiler elimina useMemo e useCallback em React 19. Veja como ativar no Next.js App Router, limitações e armadilhas em 2026.
O React Compiler memoiza automaticamente seus componentes e valores, sem que você precise escrever um único useMemo ou useCallback. Na prática: o compilador analisa seu código no build e injeta a memoização onde faz sentido, o que deveria reduzir drasticamente o número de re-renders desnecessários em uma app React 19.
Mas será que funciona de verdade em uma app Next.js App Router em produção, hoje? A gente investigou, testou em um projeto real, e aqui está o que achamos: ativação, limitações e casos onde é melhor não mexer.
O que é o react compiler, na prática
O React Compiler é uma ferramenta que roda no momento do build e transforma seu código-fonte para injetar automaticamente memoização. Sem nova API para aprender, sem hook adicional. Ele lê seus componentes como você os escreve hoje, com props, states, dependências, e deduz sozinho onde um useMemo ou useCallback manual teria sido necessário.
Antes do compilador, um desenvolvedor tinha que adivinhar quais cálculos custosos mereciam ser memoizados e listar manualmente as dependências de cada hook. Adivinhar mesmo, é a palavra certa. A gente já se viu esquecendo uma dependência em um array useCallback e debugando um state obsoleto por duas horas.
O compilador remove essa responsabilidade humana. Aplica uma regra simples: se um componente respeita as regras de React (sem mutação direta de props, sem efeitos colaterais no render), pode ser analisado estaticamente e memoizado automaticamente.
O que muda de verdade para sua equipe: o código fica mais curto, mais legível e, principalmente, mais difícil de quebrar por erro. Uma observação que surpreende muitas equipes na migração: remover manualmente todos os useMemo existentes às vezes melhora a performance, porque o compilador faz um trabalho mais fino do que um humano com pressa teria escrito manualmente.
O que o compilador não faz
Não substitui a lógica de negócio. Também não adivinha suas intenções de negócio, se seu componente tem um bug de lógica, o compilador nunca vai corrigir. Otimiza o render, ponto.
Como ativar em uma app next.js app router
A ativação acontece no nível do build, via um plugin Babel dedicado configurado no seu projeto. Em um projeto Next.js App Router existente, o processo típico é assim:
- Instale o plugin do compilador React como dependência de desenvolvimento.
- Ative-o na configuração Next.js (
next.config.js), geralmente via uma opção experimental enquanto a funcionalidade continua evoluindo. - Execute um build completo e compare o bundle antes/depois, o compilador adiciona código de memoização, então o tamanho do bundle pode aumentar levemente.
- Teste em profundidade os componentes com state complexo: formulários multi-passo, listas filtráveis, tudo que depende de re-renders precisos.
- Remova progressivamente os
useMemo/useCallbackmanuais existentes, não tudo de uma vez.
O passo 5 é aquele que todo mundo erra. Quer limpar o código de uma vez depois de ativar. Má ideia. O compilador coexiste muito bem com código já memoizado manualmente, então nada obriga a reescrever tudo no dia da ativação.
As armadilhas que enfrentamos testando o compilador
Aqui, precisa ser honesto: nem sempre tudo funciona magicamente.
Primeira armadilha: componentes que violam discretamente as regras de React, mutação direta de um objeto passado em props, efeito colateral escondido em um render condicional, simplesmente não são otimizados pelo compilador. Pior, podem produzir comportamentos inconsistentes entre modo dev e modo compilado, o que torna o debug mais difícil que antes.
Segunda armadilha: as libraries de terceiros. Se sua app depende de componentes externos que não respeitam essas regras, o compilador simplesmente as deixa de lado. Você não tem um ganho uniforme em toda a app, mas um ganho concentrado no seu próprio código.
Terceira armadilha, mais sutil: em um projeto onde os desenvolvedores já tinham feito trabalho rigoroso de memoização manual, o ganho de performance medido era fraco. O compilador brilha principalmente onde a equipe não tinha tempo ou disciplina para memoizar corretamente, o que é o caso da maioria dos projetos, sejamos honestos.
Essa abordagem tem uma limitação clara: não funciona bem se sua codebase contém muitos componentes de classe legados ou código que manipula o DOM diretamente fora do ciclo de render React. Nesse caso, migrar para componentes funcionais padrão antes de ativar o compilador é um pré-requisito obrigatório.
Tabela comparativa: memoização manual vs react compiler
| Critério | Memoização manual (useMemo/useCallback) | React Compiler |
|---|---|---|
| Esforço do desenvolvedor | Alto, cada caso a identificar e codificar | Baixo, automático no build |
| Risco de erro | Dependências esquecidas, bugs de state obsoleto | Reduzido, mas depende do respeito às regras React |
| Legibilidade do código | Pesada com hooks espalhados | Código-fonte mais próximo do render natural |
| Cobertura | Direcionada onde o dev pensou em adicionar | Uniforme em todo componente conforme |
| Compatibilidade com libraries | Não afetado | Não se aplica a componentes externos não conformes |
| Maturidade em 2026 | Standard há anos | Disponível mas ainda marcado como experimental em algumas configs |
Conclusão
Três coisas a lembrar antes de ativar o React Compiler em seu próximo projeto Next.js. Primeiro, não substitui o rigor: código que viola as regras de React continua sendo código que o compilador não consegue salvar. Depois, o ganho real depende do estado atual de sua codebase, quanto mais sua memoização manual era desleixada, mais o ganho será visível. Por fim, a migração deve ser progressiva: ativar, testar, depois limpar o código existente, nunca o contrário.
Se sua equipe já trabalha em uma migração Next.js maior, a gente falava justamente sobre isso no artigo sobre o fim de vida do Next.js 15 e o plano de migração para a versão 16, o compilador faz parte dos projetos a integrar nessa roadmap em vez de tratá-lo como um projeto separado. E se o tema do build e do compilador em geral interessa você, a gente também investigou o que muda o compilador TypeScript nativo em Go para seus tempos de build.
Precisa de um audit antes de migrar sua app para o React Compiler? Entre em contato com fstck.co para a gente analisar junto se sua codebase está pronta.
Perguntas frequentes
O react compiler funciona com componentes de classe react?
Não. O compilador analisa apenas componentes funcionais e hooks. Uma base de código com muitos componentes de classe legados deve primeiro ser migrada para componentes funcionais antes de poder se beneficiar do compilador.
Preciso remover todos os usememo e usecallback existentes após ativar o compilador?
Não, e até é desaconselhado fazer tudo de uma vez. O compilador coexiste sem problemas com código já memoizado manualmente. Melhor ativar, medir e depois limpar progressivamente componente por componente.
O react compiler deixa o tempo de build mais lento em um projeto next.js grande?
Sim, a análise estática adiciona um custo ao build, geralmente moderado em projetos de tamanho médio. Em monorepos muito grandes, esse custo merece ser medido antes de ir para produção, comparando os tempos de build antes/depois no seu CI.
Posso usar o react compiler com next.js pages router ou só com app router?
O compilador age no nível do build Babel, independente do roteador usado. Funciona em teoria com Pages Router também, mas a maioria dos relatos de experiência e documentação se concentra em projetos App Router em 2026.
Como sei se meu código respeita as regras de react necessárias para o compilador?
Um plugin ESLint dedicado permite detectar violações antes mesmo de ativar o compilador no build. É o primeiro passo recomendado: rodar o linter em toda a codebase, corrigir as violações sinalizadas e só depois ativar o compilador.
