React Compiler em 2026: memoização automática e perguntas de entrevista

O React Compiler atingiu sua versão estável v1.0 em outubro de 2025, transformando de forma fundamental a abordagem de otimização de performance em aplicações React. Para entrevistas técnicas em 2026, compreender os mecanismos internos do compilador, sua estratégia de memoização e os cenários onde a otimização manual ainda se aplica tornou-se um diferencial competitivo.

O que é o React Compiler e como ele otimiza o código?

O React Compiler é um compilador de otimização que opera em tempo de build. Ele analisa componentes e hooks do React e insere memoização granular onde isso traz benefícios. Diferente da memoização manual com useMemo ou useCallback, o compilador consegue memoizar de forma condicional e com uma granularidade mais fina do que qualquer desenvolvedor manteria de forma razoável manualmente.

O compilador funciona como um plugin do Babel (com suporte crescente do SWC a partir do Next.js 15.3.1+). Ele processa cada componente de forma independente, transformando o AST do Babel em uma Representação Intermediária de Alto Nível (HIR) customizada antes de executar múltiplas passadas de otimização.

Os resultados em produção da Meta confirmam o impacto: a Quest Store registrou até 12% de melhoria nos tempos de carregamento inicial e mais de 2,5x de aceleração nas interações. O Sanity Studio reportou uma redução de 20 a 30% no tempo de renderização em 1.231 componentes compilados.

Estrutura de resposta para entrevista: Definir o compilador, explicar que ele opera em tempo de build (não em runtime), mencionar o pipeline HIR e citar métricas reais.

O pipeline de compilação: do código-fonte ao código otimizado

Essa pergunta avalia o entendimento aprofundado. O pipeline do React Compiler possui sete fases distintas:

1. Código-fonte para AST — O Babel analisa JavaScript/TypeScript e gera uma Árvore de Sintaxe Abstrata
2. AST para HIR — O compilador transforma o AST em sua Representação Intermediária de Alto Nível, projetada especificamente para o modelo de componentes do React
3. Transformação SSA — A Atribuição Estática Única garante que cada variável seja atribuída exatamente uma vez, possibilitando rastreamento preciso do fluxo de dados
4. Inferência de tipos e análise de efeitos — O compilador classifica as operações pelos seus efeitos: leitura, armazenamento, captura, mutação, congelamento
5. Análise reativa — Cada expressão é classificada como estática (constantes, imports) ou reativa (derivada de props, estado, contexto)
6. Descoberta de escopos — O compilador identifica escopos de memoização independentes que podem ser armazenados em cache e invalidados separadamente
7. Geração de código — JavaScript otimizado com memoização automática é emitido

// Before compilation
function UserProfile({ user, theme }) {
  const fullName = user.firstName + ' ' + user.lastName;
  const style = { color: theme.primary, fontSize: 16 };
  return <div style={style}>{fullName}</div>;
}

// After compilation (simplified representation)
function UserProfile({ user, theme }) {
  const $ = useMemoCache(4);
  let fullName;
  if ($[0] !== user.firstName || $[1] !== user.lastName) {
    fullName = user.firstName + ' ' + user.lastName;
    $[0] = user.firstName;
    $[1] = user.lastName;
    $[2] = fullName;
  } else {
    fullName = $[2];
  }
  // style and JSX similarly memoized...
}

O insight essencial para entrevistas: o compilador memoiza no nível de valores, não no nível de componente. Cada valor computado recebe seu próprio slot de cache, invalidado apenas quando suas dependências específicas mudam. Essa granularidade supera o que o useMemo consegue alcançar na prática.

Regras do React: o que o compilador assume

O React Compiler realiza análise estática sob a premissa de que os componentes seguem as regras do React. Quando o código viola essas regras, o compilador pula a otimização daquele componente — silenciosamente. Esse tema aparece com frequência em entrevistas.

As três regras fundamentais:

• Componentes e hooks devem ser puros — Com as mesmas entradas, a renderização deve produzir a mesma saída. Nenhuma leitura ou escrita de estado mutável externo durante a renderização.
• Hooks devem seguir as convenções de chamada — Hooks não podem ser chamados condicionalmente, dentro de loops ou em funções aninhadas.
• Props e estado são imutáveis dentro de uma renderização — Nunca mutar props ou estado diretamente; sempre utilizar as funções setter.

// Rule violation: mutating during render
function BadCounter({ items }) {
  // The compiler will skip this component
  items.sort(); // Mutates the prop array!
  return <ul>{items.map(i => <li key={i}>{i}</li>)}</ul>;
}

// Correct: create a new sorted array
function GoodCounter({ items }) {
  const sorted = [...items].sort();
  return <ul>{sorted.map(i => <li key={i}>{i}</li>)}</ul>;
}

Integração com ESLint: detectando violações antes do build

O pacote independente eslint-plugin-react-compiler foi descontinuado no final de 2025. Todas as regras de lint relacionadas ao compilador agora estão no eslint-plugin-react-hooks@latest.

Configuração com ESLint flat config:

import reactHooks from 'eslint-plugin-react-hooks';
import { defineConfig } from 'eslint/config';

export default defineConfig([
  reactHooks.configs.flat.recommended,
]);

As regras alimentadas pelo compilador detectam três padrões críticos:

• set-state-in-render — Chamar setState durante a renderização, causando loops infinitos
• set-state-in-effect — Computações custosas dentro de efeitos que disparam re-renderizações em cascata
• refs — Acessar .current em refs durante a renderização (refs são mecanismos de escape mutáveis, não seguros para renderização)

Para entrevistas, a estratégia de adoção recomendada: habilitar primeiro as regras do ESLint, corrigir todas as violações e então ativar o compilador. Essa abordagem gradual minimiza surpresas.

Quando a otimização manual ainda é necessária

O compilador não elimina todo o trabalho de performance. Vários cenários ainda requerem intervenção manual:

1. Assinaturas de stores externos

O compilador rastreia apenas o estado do React, props e contexto. Stores externos (Redux, Zustand, MobX) requerem useSyncExternalStore ou o mecanismo de seletor do próprio store para otimização de renderização.

2. Computações custosas com grandes conjuntos de dados

Embora o compilador memoize os valores de retorno, ele não avalia o custo de execução. Uma função que filtra 100.000 itens ainda é executada quando suas dependências mudam. Para operações verdadeiramente custosas, useMemo com dependências explícitas continua válido — embora o compilador não duplique a memoização.

3. Lógica imperativa baseada em refs

As refs são intencionalmente excluídas do modelo reativo do compilador. Animações, desenho em canvas e integração com bibliotecas DOM de terceiros ainda exigem controle manual.

4. Memoização entre componentes

O compilador memoiza dentro de um único componente ou hook. Compartilhar valores computados entre componentes ainda requer elevação de estado, contexto ou camadas de cache externas.

// The compiler handles this automatically
function ProductCard({ product, currency }) {
  const formattedPrice = formatCurrency(product.price, currency);
  const discount = product.originalPrice - product.price;
  return (
    <div>
      <span>{formattedPrice}</span>
      {discount > 0 && <Badge>Save {discount}</Badge>}
    </div>
  );
}

// Manual optimization still needed: expensive external computation
function DataGrid({ rows }) {
  const processedRows = useMemo(
    () => rows.map(row => heavyTransform(row)), // O(n) with large n
    [rows]
  );
  return <VirtualList items={processedRows} />;
}

Como habilitar o React Compiler em diferentes frameworks

Entrevistadores frequentemente avaliam o conhecimento prático de configuração:

Next.js (15.3.1+): Suporte nativo SWC. Habilitação no next.config.js:

const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};
export default nextConfig;

Vite 8 com @vitejs/plugin-react v6: Desde a v6 que substituiu o Babel interno pelo oxc, o compilador requer @rolldown/plugin-babel:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import babel from '@rolldown/plugin-babel';
import { reactCompilerPreset } from 'babel-plugin-react-compiler';

export default defineConfig({
  plugins: [
    react(),
    babel({ presets: [reactCompilerPreset] }),
  ],
});

Expo SDK 54+: Habilitado por padrão. Nenhuma configuração necessária.

React Compiler vs memoização manual: comparação para entrevistas

| Aspecto | React Compiler | Manual (useMemo/useCallback) | |---------|---------------|----------------------------------| | Granularidade | No nível de valores, por expressão | No nível de blocos, definido pelo desenvolvedor | | Memoização condicional | Suportada | Não é possível | | Custo de manutenção | Zero — automático | Alto — arrays de dependências, componentes wrapper | | Entre componentes | Escopo de um único componente | Escopo de um único componente | | Stores externos | Não rastreados | Não rastreados (usar useSyncExternalStore) | | Componentes de classe | Não suportados | N/A (usar React.memo) | | Requisito de build | Plugin Babel ou SWC | Nenhum | | Teto de performance | 20-60% menos re-renderizações (típico) | Depende da habilidade do desenvolvedor |

O resumo preparado para entrevista: o compilador automatiza 80 a 90% da memoização que os desenvolvedores gerenciavam manualmente, com melhor granularidade e zero custo de manutenção. Os 10 a 20% restantes envolvem integrações externas, computações verdadeiramente custosas e trabalho imperativo no DOM.

Perguntas frequentes em entrevistas com respostas concisas

P: O React Compiler opera em tempo de build ou em runtime? Em tempo de build. O compilador é um plugin do Babel que transforma o código-fonte durante a compilação. O código otimizado utiliza um helper de runtime (useMemoCache) para armazenar valores em cache, mas toda a análise acontece antes do deploy.

P: As chamadas existentes a useMemo e useCallback devem ser removidas? A equipe do React recomenda manter a memoização manual existente. Removê-la pode alterar o resultado da compilação de formas sutis. Para código novo, o mais adequado é confiar no compilador e adicionar memoização manual apenas após o profiling identificar uma necessidade específica.

P: O que acontece quando o compilador encontra código que não consegue otimizar? Ele silenciosamente pula aquele componente ou hook. A aplicação continua funcionando corretamente — aquela parte específica simplesmente executa sem memoização automática. As regras do ESLint revelam esses casos durante o desenvolvimento.

P: Como o compilador interage com os Server Components? Os Server Components são executados no servidor e produzem saída serializada — eles não são re-renderizados no cliente. O compilador tem como alvo os componentes do cliente onde as re-renderizações são a principal preocupação de performance. As duas otimizações são complementares: os Server Components reduzem o tamanho do bundle, o compilador reduz o custo de re-renderização no lado do cliente.

P: O compilador consegue otimizar hooks customizados? Sim. O compilador analisa tanto componentes quanto hooks. Um hook customizado que calcula estado derivado terá seus valores de retorno memoizados automaticamente, beneficiando cada componente que o utiliza.

Conclusão

• O React Compiler v1.0 é uma ferramenta de build que insere memoização granular no nível de valores através de um pipeline de compilação de sete fases (AST, HIR, SSA, inferência de tipos, análise de efeitos, análise reativa, geração de código)
• O compilador assume que os componentes seguem as regras do React; violações causam opt-out silencioso, detectável pelo eslint-plugin-react-hooks com o preset recommended
• A otimização manual continua necessária para assinaturas de stores externos, computações custosas com grandes conjuntos de dados, lógica imperativa baseada em refs e cache entre componentes
• A configuração prática varia por framework: nativo SWC no Next.js, @rolldown/plugin-babel no Vite 8, habilitado por padrão no Expo SDK 54+
• Em entrevistas, é fundamental articular tanto o que o compilador automatiza (80-90% da memoização) quanto o que ele não cobre (estado externo, computações custosas entre componentes, componentes de classe)
• O caminho de adoção recomendado é: regras do ESLint primeiro, depois habilitação do compilador — os entrevistadores perguntam regularmente sobre essa estratégia gradual