React Compiler en 2026: memoización automática y preguntas de entrevista

React Compiler alcanzó su versión estable v1.0 en octubre de 2025, cambiando de manera fundamental la forma en que se trabaja la optimización de rendimiento en aplicaciones React. Para las entrevistas técnicas en 2026, comprender los mecanismos internos del compilador, su estrategia de memoización y los escenarios donde la optimización manual sigue siendo necesaria se ha convertido en un diferenciador clave.

Qué es React Compiler y cómo optimiza el código

React Compiler es un compilador de optimización que se ejecuta en tiempo de build. Analiza componentes y hooks de React, e inserta memoización granular donde resulta beneficioso. A diferencia de la memoización manual con useMemo o useCallback, el compilador puede memoizar de forma condicional y con una granularidad más fina de lo que cualquier desarrollador mantendría razonablemente a mano.

El compilador opera como un plugin de Babel (con soporte creciente de SWC a partir de Next.js 15.3.1+). Procesa cada componente de forma independiente, transformando el AST de Babel en una Representación Intermedia de Alto Nivel (HIR) personalizada antes de ejecutar múltiples pasadas de optimización.

Los resultados en producción de Meta confirman el impacto: el Quest Store registró hasta un 12 % de mejora en tiempos de carga inicial y más de 2.5x de aceleración en las interacciones. Sanity Studio reportó una reducción del 20 al 30 % en el tiempo de renderizado en 1,231 componentes compilados.

Estructura de respuesta en entrevista: Definir el compilador, explicar que opera en tiempo de build (no en runtime), mencionar el pipeline HIR y citar métricas reales.

El pipeline de compilación: del código fuente al resultado optimizado

Esta pregunta evalúa la comprensión a profundidad. El pipeline de React Compiler tiene siete fases distintas:

1. Código fuente a AST — Babel analiza JavaScript/TypeScript y genera un Árbol de Sintaxis Abstracta
2. AST a HIR — El compilador transforma el AST en su Representación Intermedia de Alto Nivel, diseñada específicamente para el modelo de componentes de React
3. Transformación SSA — La Asignación Estática Única garantiza que cada variable se asigne exactamente una vez, permitiendo un rastreo preciso del flujo de datos
4. Inferencia de tipos y análisis de efectos — El compilador clasifica las operaciones por sus efectos: lectura, almacenamiento, captura, mutación, congelamiento
5. Análisis reactivo — Cada expresión se clasifica como estática (constantes, imports) o reactiva (derivada de props, estado, contexto)
6. Descubrimiento de scopes — El compilador identifica scopes de memoización independientes que pueden almacenarse en caché e invalidarse por separado
7. Generación de código — Se emite JavaScript optimizado con memoización automática

// 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...
}

El punto clave para entrevistas: el compilador memoiza a nivel de valores, no a nivel de componente. Cada valor calculado obtiene su propia ranura de caché, que solo se invalida cuando cambian sus dependencias específicas. Esta granularidad supera lo que useMemo logra en la práctica.

Reglas de React: lo que el compilador asume

React Compiler realiza análisis estático bajo la suposición de que los componentes siguen las reglas de React. Cuando el código viola estas reglas, el compilador omite la optimización de ese componente — de forma silenciosa. Este tema aparece con frecuencia en entrevistas.

Las tres reglas fundamentales:

• Los componentes y hooks deben ser puros — Con las mismas entradas, el renderizado debe producir la misma salida. No se debe leer ni escribir estado mutable externo durante el renderizado.
• Los hooks deben seguir las convenciones de invocación — Los hooks no pueden invocarse condicionalmente, dentro de bucles ni en funciones anidadas.
• Las props y el estado son inmutables dentro de un renderizado — Nunca mutar props o estado directamente; siempre utilizar las funciones 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>;
}

Integración con ESLint: detectar violaciones antes del build

El paquete independiente eslint-plugin-react-compiler quedó obsoleto a finales de 2025. Todas las reglas de lint relacionadas con el compilador ahora residen en eslint-plugin-react-hooks@latest.

Configuración con ESLint flat config:

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

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

Las reglas del compilador detectan tres patrones críticos:

• set-state-in-render — Llamar a setState durante el renderizado, causando bucles infinitos
• set-state-in-effect — Computaciones costosas dentro de efectos que desencadenan re-renderizados en cascada
• refs — Acceder a .current en refs durante el renderizado (las refs son mecanismos de escape mutables, no seguros para el renderizado)

Para entrevistas, la estrategia de adopción recomendada es: habilitar primero las reglas de ESLint, corregir todas las violaciones y luego activar el compilador. Este enfoque progresivo minimiza las sorpresas.

Cuándo la optimización manual sigue siendo necesaria

El compilador no elimina todo el trabajo de rendimiento. Varios escenarios aún requieren intervención manual:

1. Suscripciones a stores externos

El compilador solo rastrea el estado de React, las props y el contexto. Los stores externos (Redux, Zustand, MobX) requieren useSyncExternalStore o el mecanismo de selección propio del store para optimizar los renderizados.

2. Cálculos costosos con grandes conjuntos de datos

Aunque el compilador memoiza los valores de retorno, no mide el costo de ejecución. Una función que filtra 100,000 elementos se sigue ejecutando cuando cambian sus dependencias. Para operaciones verdaderamente costosas, useMemo con dependencias explícitas sigue siendo válido — aunque el compilador no duplicará la memoización.

3. Lógica imperativa basada en refs

Las refs están intencionalmente excluidas del modelo reactivo del compilador. Las animaciones, el dibujo en canvas y la integración con bibliotecas DOM de terceros aún requieren control manual.

4. Memoización entre componentes

El compilador memoiza dentro de un solo componente o hook. Compartir valores calculados entre componentes sigue requiriendo elevar el estado, usar contexto o capas de caché 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} />;
}

Cómo habilitar React Compiler en diferentes frameworks

Los entrevistadores suelen evaluar el conocimiento práctico de configuración:

Next.js (15.3.1+): Soporte nativo SWC. Se habilita en next.config.js:

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

Vite 8 con @vitejs/plugin-react v6: Desde la v6 que reemplazó Babel interno por oxc, el compilador requiere @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 defecto. No requiere configuración.

React Compiler vs memoización manual: comparación para entrevistas

| Aspecto | React Compiler | Manual (useMemo/useCallback) | |---------|---------------|----------------------------------| | Granularidad | A nivel de valores, por expresión | A nivel de bloques, definido por el desarrollador | | Memoización condicional | Soportada | No es posible | | Costo de mantenimiento | Nulo — automático | Alto — arreglos de dependencias, componentes wrapper | | Entre componentes | Scope de un solo componente | Scope de un solo componente | | Stores externos | No rastreados | No rastreados (usar useSyncExternalStore) | | Componentes de clase | No soportados | N/A (usar React.memo) | | Requisito de build | Plugin Babel o SWC | Ninguno | | Techo de rendimiento | 20-60 % menos re-renderizados (típico) | Depende de la habilidad del desarrollador |

El resumen preparado para entrevista: el compilador automatiza el 80-90 % de la memoización que los desarrolladores manejaban manualmente, con mejor granularidad y cero costo de mantenimiento. El 10-20 % restante involucra integraciones externas, cálculos verdaderamente costosos y trabajo imperativo en el DOM.

Preguntas frecuentes en entrevistas con respuestas concisas

P: React Compiler opera en tiempo de build o en runtime? En tiempo de build. El compilador es un plugin de Babel que transforma el código fuente durante la compilación. El resultado optimizado utiliza un helper de runtime (useMemoCache) para almacenar valores en caché, pero todo el análisis ocurre antes del despliegue.

P: Se deben eliminar las llamadas existentes a useMemo y useCallback? El equipo de React recomienda mantener la memoización manual existente. Eliminarla puede alterar el resultado de la compilación de formas sutiles. Para código nuevo, lo apropiado es confiar en el compilador y agregar memoización manual solo después de que el perfilado identifique una necesidad específica.

P: Qué sucede cuando el compilador encuentra código que no puede optimizar? Omite silenciosamente ese componente o hook. La aplicación sigue funcionando correctamente — esa pieza específica simplemente se ejecuta sin memoización automática. Las reglas de ESLint revelan estos casos durante el desarrollo.

P: Cómo interactúa el compilador con los Server Components? Los Server Components se ejecutan en el servidor y producen una salida serializada — no se re-renderizan en el cliente. El compilador apunta a los componentes del cliente donde los re-renderizados son la principal preocupación de rendimiento. Las dos optimizaciones son complementarias: los Server Components reducen el tamaño del bundle, el compilador reduce el costo de los re-renderizados del lado del cliente.

P: El compilador puede optimizar hooks personalizados? Sí. El compilador analiza tanto componentes como hooks. Un hook personalizado que calcula estado derivado tendrá sus valores de retorno memoizados automáticamente, beneficiando a cada componente que lo utilice.

Conclusión

• React Compiler v1.0 es una herramienta de build que inserta memoización granular a nivel de valores a través de un pipeline de compilación de siete fases (AST, HIR, SSA, inferencia de tipos, análisis de efectos, análisis reactivo, generación de código)
• El compilador asume que los componentes siguen las reglas de React; las violaciones causan un opt-out silencioso, detectable con eslint-plugin-react-hooks y el preset recommended
• La optimización manual sigue siendo necesaria para suscripciones a stores externos, cálculos costosos con grandes conjuntos de datos, lógica imperativa basada en refs y caché entre componentes
• La configuración práctica varía según el framework: nativo SWC en Next.js, @rolldown/plugin-babel en Vite 8, habilitado por defecto en Expo SDK 54+
• En entrevistas, es fundamental articular tanto lo que el compilador automatiza (80-90 % de la memoización) como lo que no cubre (estado externo, cálculos costosos entre componentes, componentes de clase)
• La ruta de adopción recomendada es: reglas de ESLint primero, luego habilitación del compilador — los entrevistadores preguntan regularmente sobre esta estrategia gradual