Lecciones de la Adopción de React Compiler

Hola, espero que estén pasando un buen momento en React Summit 2025. Bienvenidos a mi charla donde compartiré mis aprendizajes al adoptar el último y mejor React Compiler en un proyecto del mundo real. Mi nombre es Akash Hamilwasia. Trabajo como ingeniero en Eleven Labs, donde estamos construyendo la mejor plataforma de audio AI que existe, incluyendo productos como Text-to-Speech, Voice Changer, Voice Cloning, Voice Design, Agents, y mucho, mucho más. Puedes seguirme en Twitter. Mi nombre de usuario es Lenderschool. También me encanta compartir proyectos en GitHub. Puedes ver algunos de mis proyectos, nuevamente con el mismo nombre de usuario, en Lenderschool. Me gusta compartir mis aprendizajes en forma de blogs técnicos y charlas en varias conferencias, las grabaciones de las cuales puedes encontrar en mi sitio web personal akashhamilwasia.com.

En mi tiempo libre, construyo una herramienta de creación de videos llamada Slantit. Slantit es una herramienta muy simple y fácil de usar {{^}}En mi tiempo libre, construyo una herramienta de creación de videos llamada Slantit. Slantit es una herramienta que te permite crear videos de productos impresionantes a partir de grabaciones de pantalla simples de manera muy fácil.

Solo tienes que soltar una grabación de pantalla, seleccionar algunas animaciones y efectos 3D, y obtienes un bonito video de producto que puedes compartir en Product Hunt, en redes sociales o en presentaciones de lanzamiento de productos. Ahora, Slantit es una pieza de software muy compleja. Tiene una línea de tiempo, puedes arrastrar clips, puedes cambiar el tamaño de las cosas, moverlas. Es un editor de video completo que se ejecuta en el navegador. Puedes verlo en slantit.app. Y la razón por la que menciono Slantit es porque aplicaciones pesadas en UI y de creatividad como Slantit deben ser extremadamente eficientes para una gran experiencia de usuario.

Ahora React hace que sea increíblemente fácil construir interfaces complejas como esta de manera declarativa. Pero en cierto punto, no puedes ignorar el rendimiento de estas UIs complejas. Ahora, esta es una instantánea de nuestro React Profiler Flame Graph, algo con lo que todos estamos bastante familiarizados. Y esta es una captura de pantalla de Slantit mostrando qué componentes se están renderizando y cuándo. Quiero llamar su atención a este componente de clip corto. Este componente renderiza los clips individuales que el usuario agrega en la línea de tiempo. Y en la propia línea de tiempo, el usuario puede agregar, digamos, 20, 30, 40 clips diferentes dependiendo de lo que estén creando.

Ahora, cada vez que el seek de la línea de tiempo cambiaba en Slantit, todos los componentes en ese subárbol de la línea de tiempo se volvían a renderizar, lo que significa que todos estos componentes de clip corto, que ni siquiera dependen del valor cambiante en la línea de tiempo, también se volvían a renderizar, llevando a renderizaciones innecesarias. Ahora React nos ha proporcionado formas de solucionar estas renderizaciones innecesarias usando una técnica llamada memoización. Y hay APIs como React.memo, que te permiten envolver un componente y solo volver a renderizarlos cuando sus props cambian. También hay hooks como UseMemo, que te permiten memoizar cierta lógica dentro de tu componente y solo volver a ejecutarlos cuando sus dependencias cambian.

Algunos de ustedes pueden no saberlo, pero también pueden usar UseMemo para devolver JSX. Y esto puede ayudar a memoizar ciertas partes de la UI dentro de tus componentes. Así que en este caso, estoy memoizando el componente de menú y solo se volverá a renderizar cuando name, handle, duplicate, o cualquiera de las dependencias realmente cambien. Similar a esto, también hay un hook de use callback, que funciona como UseMemo, pero es para funciones. Así que si estamos definiendo alguna función dentro de tu componente, puedes envolverla para que el componente solo se redefina cuando las dependencias realmente cambien. Ahora, usando estas APIs, realmente puedes reducir muchas renderizaciones innecesarias, pero es muy engorroso y difícil de acertar. Necesitas averiguar qué componente se está volviendo a renderizar y cuándo, dónde tienes que aplicar la memoización, y ver si las props que se están pasando a los componentes también deben ser memoizadas.

Por ejemplo, si estás usando React.memo en un componente, pero estás pasando funciones que se están redefiniendo en el propio componente, necesitas memorizarlas también, con el hook use callback. Así que es bastante difícil, bastante engorroso, y honestamente, podrías pasar muchos años averiguando dónde deberías aplicar la memoización.

Para resolver estos problemas en 2024, el equipo de React lanzó React Compiler en beta. El trabajo de React Compiler es realizar la memoización automática de tu código React a través del análisis estático de código. Ya se utiliza en Meta en producción. Y hace solo unas semanas, el 7 de octubre de 2025, el equipo de React lanzó React Compiler en beta. Y hace solo unas semanas, el 7 de octubre de 2025, React Compiler tuvo su primer lanzamiento estable 1.0 en React Conf 2025.

El objetivo del compilador es asegurar que solo las partes relevantes de tu aplicación se vuelvan a renderizar cuando el estado cambia. Esto también se conoce como reactividad de grano fino, y siempre que tengas algún estado que cambie, solo quieres que la UI o la lógica que dependa de ese estado cambie. No quieres que toda la aplicación se vuelva a renderizar o todo el componente. Solo las partes que realmente dependen de ese estado deberían volver a renderizarse. React Compiler hace esto realizando un análisis estático de tu código basado en las reglas de React.

Echemos un vistazo a cuáles son estas reglas. Puedes encontrar una lista completa de todas estas reglas en la documentación de React. Solo las repasaré rápidamente. El primer grupo de reglas cubre esta naturaleza específica de los componentes y hooks, que son puros. Así que si tienes efectos secundarios ejecutándose en tu componente, asegúrate de ejecutarlos fuera del renderizado. Props y estado y argumentos y valores de retorno de hooks son inmutables por naturaleza.

Y la segunda regla dice que React llama a componentes y hooks. No se supone que llamemos directamente a los componentes como funciones, o que pasemos valores de hooks como valores regulares y los llamemos dinámicamente. Deben ser llamados estáticamente en el nivel superior. El tercer grupo son las reglas de los hooks en sí. Así que si alguna de estas reglas se rompe, el compilador omitiría ese componente o hook en particular.

Y digamos que si tienes un gran árbol de componentes que se están renderizando, o un gran árbol de llamadas de hooks, si hay un componente o hook en particular que está rompiendo estas reglas, solo ese componente o hook en particular será omitido. El resto del subárbol continuará optimizándose, basado en si realmente están pasando las reglas de React o no.

Para ver el compilador en acción, aquí tienes un ejemplo básico. Así que este es un componente de Slanted donde estoy renderizando dos deslizadores. Y cuando paso esto a través del React compiler, esto es lo que obtengo como resultado. Es bastante código, bastante confuso, muy difícil de leer. Pero si dedicas algo de tiempo a tratar de entender lo que realmente está haciendo, está haciendo un análisis de dependencias en varias partes de tu código de React y memorizándolas y almacenándolas en caché según lo que realmente está cambiando.

Así que en la primera rama if, verifica si la función de actualización ha cambiado. Si eso ha cambiado, crea una nueva función que llama a la función de actualización. Si no ha cambiado, simplemente usa el valor de la caché. En la segunda rama if, verifica si el valor de desenfoque o el callback ha cambiado. Si ambos han cambiado, renderiza el deslizador de número de configuraciones. De lo contrario, simplemente usa el valor que está en la caché y así sucesivamente.

Ahora, esto podría parecer una IA inteligente que está haciendo lo suyo y averiguando qué es lo que realmente está cambiando, pero es solo análisis de código estático en acción. Si piensas que esto es gen AI o AGI, lo siento, esto es solo análisis de código que ha estado ahí desde el amanecer de los lenguajes de programación y el compilador. Así que para comenzar, asegúrate de estar en React versión 19. Aún puedes usar el compilador con React 18 y 17 a través del paquete de tiempo de ejecución del React compiler. Y la documentación tiene instrucciones para usar el compilador con Next.js, Vite, o incluso un proyecto de React Native. Así que el compilador no es solo una cosa web. Puedes usarlo con cualquier proyecto que use React.

Hay dos paquetes que debes tener en cuenta. El primero es el Babel plugin React compiler, que es el compilador de React real que realiza las transformaciones disponible como un plugin de Babel. Y el segundo paquete es el ESLint plugin React package, que es un plugin de ESLint que muestra cualquier error o análisis del compilador basado en las reglas de React. Mi sugerencia sería comenzar a usar el ESLint plugin hoy, incluso si no te sientes cómodo usando el compilador desde el principio. Y recuerda, no es necesario optimizar el 100% de tu aplicación desde el principio.

Hay instrucciones en la documentación donde puedes comenzar adoptando el compilador en ciertas partes de tu base de código y aumentando lentamente la cobertura a medida que te sientas más y más cómodo con cómo funciona el compilador. Una vez que tengas el compilador habilitado, verás insignias azules en React DevTools junto a los componentes. Estas insignias azules con el emoji de memo y destellos indican que han sido auto-memoizados por el React compiler. Ahora, en Slanted, con el compilador habilitado, el compilador pudo auto-memoizar 218 de 237 componentes, lo que es aproximadamente el 92% de la cobertura de componentes.

Ahora, ten en cuenta que ya tenía algunas optimizaciones en su lugar. Así que el tiempo y los componentes relacionados, que sabía que eran una parte sensible al rendimiento de la aplicación, ya apliqué memoización manual en ciertos componentes allí. Y también uso este concepto de micro-global stores donde las partes de la UI, que realmente dependen de ciertas partes del estado global, se vuelven a renderizar solo cuando sus dependencias cambian, no cuando todo el estado global se actualiza. Una vez que habilité el compilador, comencé a ver instantáneamente menos re-renderizados en partes no optimizadas de la aplicación.

Así que cosas como la barra lateral, que no son realmente sensibles al rendimiento, se estaban re-renderizando bastante, pero realmente no causaban ningún problema de rendimiento. Comenzaron a renderizarse mucho menos en comparación con lo que eran antes.

Así que aquí hay un antes y un después. Cuando muevo cosas en la línea de tiempo, observa cómo todo el componente del reproductor de video se está re-renderizando todos los botones, todos los deslizadores. Cuando cambio el deslizador, el interruptor, el texto, todo se está re-renderizando en esa caja. Con el compilador habilitado, cuando cambio algo en la línea de tiempo, el reproductor de video no se re-renderiza. Solo el deslizador de progreso cambia porque ese valor ha cambiado. E incluso cuando cambio el deslizador, el interruptor, el texto no se re-renderizan.

Solo el deslizador está cambiando, que depende del valor que ha sido actualizado. Ahora esto se ve realmente bien, pero desafortunadamente, React Compiler aún no es una bala de plata. Una bala de plata es algo que simplemente funciona mágicamente desde el principio. No tienes que pensar en ningún caso límite o en cualquier advertencia que pueda tener. Pero honestamente, al usar el compilador, encontré algunos problemas y advertencias, de los cuales quiero hacerte consciente cuando estés adoptando React Compiler en tu aplicación de producción.

La primera advertencia que encontré fue vi una pérdida de reactividad en algunas partes de mi aplicación. Para entender esto mejor, necesito mostrarte cómo Slanted mantiene parte de su estado. Así que la línea de tiempo de Slanted se mantiene como un objeto global. Y uso getters para calcular ciertos valores importantes de esta línea de tiempo. Así que aquí estoy calculando la duración basada en los clips que tiene la línea de tiempo. Similar a esto, tengo múltiples otras propiedades como el progreso del tiempo actual, todo lo cual se calcula basado en los datos actuales dentro de este objeto de línea de tiempo. El objeto de línea de tiempo en sí mismo vive fuera de React y es un estado global al que puedo acceder en cualquier parte de mi aplicación.

Ahora, mi error fue usar directamente este objeto global y usar la propiedad de duración para renderizar la duración de la línea de tiempo dentro de un componente de React. Ahora, esto funcionaba cuando teníamos re-renderizados excesivos ocurriendo donde el componente padre que estaba usando VideoPlayer se re-renderizaba cada vez que la línea de tiempo cambiaba por alguna razón no relacionada. Y es por eso que la duración que se renderizaba por este componente VideoPlayer también parecía actualizarse. Pero con los re-renderizados excesivos eliminados el componente no se re-renderizaba cuando la duración cambiaba y el compilador realmente no informaba esto porque era semánticamente correcto. Esta era una variable global que no está bajo el ámbito de React. No es un estado de React que necesite desencadenar un re-renderizado. Y es por eso que cuando la duración cambiaba el componente no se re-renderizaba, lo que llevaba a que no hubiera actualización en la UI. Así es como se veía.

Así que nota cuando estoy agregando elementos en la línea de tiempo dentro del círculo rojo, la duración de la línea de tiempo no ha cambiado. Cuando intento mover cosas, ciertos valores se vuelven infinitos y problemas desagradables para tener. Y cuando los ves en tu aplicación, no se ve bien. Pude solucionar este problema usando un paquete llamado Valtio para reactividad basada en proxy. Ahora, Slanted es una aplicación muy compleja y para algunas de las actualizaciones de estado estoy usando actualizaciones basadas en mutación. Y Valtio permite reactividad basada en proxy. Así que puedo desencadenar directamente una actualización cuando ciertas propiedades de un objeto de estado muy grande cambian. Ahora, con las cosas aplicadas, el componente ahora solo se re-renderiza cuando el valor de duración cambia en lugar de cuando cambia toda la línea de tiempo. Porque el reproductor de video solo depende de la duración, solo quiero que se re-renderice cuando la duración cambia. Y Valtio lo hace posible porque aplica estas actualizaciones y desencadena re-renderizado solo cuando los valores dependientes cambian.

Así que en resumen, si notas pérdida de reactividad en algunas partes de tu aplicación, recuerda, no es culpa del compilador. Probablemente sea tu culpa debido a algún código defectuoso que parecía funcionar antes de que se introdujera el compilador. Y esto generalmente se detecta usando pruebas. Pero seamos honestos, ¿cuántos de nosotros tenemos pruebas reales para probar tales cosas? Se puede resolver usando React State o cualquier biblioteca de gestión de estado para convertir cualquier estructura no reactiva que puedas tener en un estado reactivo que pueda desencadenar actualizaciones en tu componente.

La segunda advertencia que encontré fue cómo React Compiler trataba las memoizaciones manuales incorrectas. Así que cada vez que se encuentra una memoización manual incorrecta, el compilador simplemente omite optimizar tales componentes o hooks. Así que aquí hay un ejemplo de un hook que tenía en Slanted. Y si te tomas un momento para notar qué está mal, el error aquí que tengo es que no estoy pasando todos los valores dependientes en el área de dependencia del hook use callback. Aquí, solo estoy pasando value y set value, pero también depende de min, max y step. Ahora, este es un hook memoizado incorrectamente, y es por eso que el React Compiler omitiría memoizar este hook en particular.

Así que si tienes memoizaciones incorrectas aplicadas en tu base de código, el compilador omitiría optimizar tales componentes o hooks. De hecho, puede tener un efecto en cascada en otros componentes. Así que digamos que este hook en particular, porque no fue memoizado correctamente, tampoco será auto-memoizado por el compilador. Y donde sea que se use, eso podría tener algunos problemas de re-renderizado.

Para solucionar esto, asegúrate de tener la matriz de dependencias de useMemo y useCallback correcta, y lo bueno es que el compilador realmente te dice qué falta. Así que cuando paso mi hook dentro de React Compiler, dice que, oye, te faltan los valores min y max, así que probablemente deberías añadir eso. Y esto es sinceramente bastante útil. Esto parece un problema muy pequeño, pero en realidad es bastante común, y puede suceder mucho cuando trabajas en equipos. Donde he trabajado en un hook, he escrito la matriz de dependencias exacta, que se utiliza en la lógica, pero otra persona entra, actualiza la lógica, pero olvida actualizar la matriz de dependencias.

La solución para esto es simplemente actualizar la matriz de dependencias para tener todas las dependencias, o incluso mejor, simplemente eliminar la memoización manual y dejar que React Compiler haga su magia. Ahora te estarás preguntando, ¿cómo encuentro tales problemas de compilación? Bueno, la mejor manera es usar el plugin eslint para ver el análisis del compilador en el propio editor. Te mostrará dónde estás rompiendo las reglas de React, qué deberías hacer para solucionarlas, y también te guía a la documentación correcta para entender cuál sería la solución real para ese escenario particular. También puedes usar el React Compiler Playground para ver el análisis y los problemas y la salida del compilador directamente en la web. Así que puedes simplemente traer tu código, no tienes que preocuparte por instalar dependencias o cualquier otra cosa, es análisis estático, así que simplemente traes tu código JavaScript o cualquier código TypeScript, y puedes ver la salida, cualquier error o cualquier problema. Es sinceramente una herramienta realmente genial para realmente aprender cómo está funcionando el compilador y cómo está trabajando internamente también.

Ahora, la tercera advertencia que encontré fue que las bibliotecas externas que usas en tu proyecto no serán optimizadas automáticamente a menos que la propia biblioteca use el compilador durante la construcción. Ahora, este fue un hallazgo sorprendente. Pensé que todo mi proyecto sería optimizado, incluyendo cualquier componente externo que pudiera estar usando. Pero noté que muchos de mis componentes seguían re-renderizándose, y estos componentes realmente no fueron escritos por mí. Venían de un paquete de terceros que estaba usando. En este caso, viene de un paquete llamado RQI, que proporciona componentes de alto nivel para elementos comunes de UI como acordeón, menú, y así sucesivamente. Así que estos componentes no fueron memorizados por el compilador y seguían re-renderizándose debido a algún re-renderizado innecesario. Ahora, esto no es ideal. Desearía que hubiera una mejor solución, pero sinceramente la solución es que el compilador se ejecute en el código fuente real de la biblioteca y se publique la nueva versión usando el compilador en el proceso de construcción, y luego puedes instalarlo y obtener el beneficio completo del compilador.

Si eres autor de una biblioteca, instala React Compiler en tu proceso de construcción para que todos podamos beneficiarnos de las características de React Compiler en nuestra base de código también.

La cuarta advertencia que me gustaría discutir es que a veces la salida del compilador no es realmente ideal. Así que para explicar esto, aquí tengo un componente muy simple. Estoy renderizando una UI condicional usando una bandera que está habilitada aquí. Código JSX típico, justo como hacemos las cosas para renderizar UI condicionalmente. Cuando pasas esto a través del compilador, esta es la salida que obtenemos. Al principio, esto parece correcto, pero hay un problema evidente aquí donde el primer deslizador, que es el deslizador de fuerza de desenfoque y el deslizador de radio focal, ambos en realidad cambian cuando cualquiera de los valores de desenfoque o radio cambia. Ambos son realmente independientes entre sí, pero debido a cómo está escrito el código JSX usando el condicional, React Compiler acopla ambas optimizaciones para que dependan de cualquiera de los cambios de valor de desenfoque o radio.

Así que si solo muestro cómo se ve la salida, cada vez que cambio el deslizador de radio focal en la UI, incluso el deslizador de fuerza de desenfoque está cambiando, pero ambos son realmente independientes. Cuando el radio focal cambia, solo ese deslizador particular necesita ser actualizado. Entonces, ¿cómo solucionamos este problema? Así que probé un montón de cosas. Pude realmente solucionar este problema usando un iffy. Así que con un iffy en la función de renderizado, pude usar una declaración if para renderizar condicionalmente ese JSX particular y el compilador pudo optimizar esto perfectamente donde ahora el deslizador de fuerza de desenfoque solo depende del valor de desenfoque y el deslizador de radio focal depende solo del valor de radio focal.

Ahora, el enfoque iffy no se ve bien. Personalmente, nunca he usado iffy de esta manera, o incluso si lo he hecho, lo extraería como un componente separado y eso es lo que intenté a continuación. Así que extraje la parte condicional como un componente temporal separado y toma todos los props y luego rendericé mi JSX como de costumbre y esto también funcionó perfectamente bien con el compilador donde ahora el componente temporal depende tanto de blur como de radius, pero dentro del componente temporal, el deslizador de fuerza de desenfoque de configuración depende solo del blur y el radio focal solo depende del valor de radius. Ahora esto se ve genial, pero honestamente es mucho trabajo extraer componentes manualmente. No pude averiguar cómo el compilador podría realmente hacer esto. Creo que hay una bandera tal vez para habilitar esto donde el compilador puede auto-extraer tales componentes y crear estos componentes intermedios y aplicar las memorizaciones por sí mismo.

Ahora te estarás preguntando, ¿cómo puedo medir el impacto del compilador después de haberlo habilitado? Puedes usar React Profiler o React Scan para ver qué componentes se renderizaron y por qué. Con React Scan, realmente lo hace muy fácil. Simplemente insertas el script de React Scan en tu base de código y resalta en vivo qué componentes se han vuelto a renderizar, cuántas veces se ha vuelto a renderizar y también te permite seleccionar un componente en particular y ver por qué se volvió a renderizar, qué props cambiaron, si alguna referencia cambió lo que llevó a esa re-renderización. Así que es súper útil, mucho más rápido que React Profiler y es realmente útil para ver si el compilador está haciendo su trabajo.

Puedes consultar React Scan en reactscan.com, pero también puedes usar el buen viejo React Profiler para realmente crear un Flame Graph y ver si hay menos re-renderizaciones con el compilador habilitado. Aquí está el Flame Graph con el compilador deshabilitado en Slanted. Observa cómo el componente Video Player se está volviendo a renderizar cuando un cierto campo cambia en la aplicación y muchos de los componentes de short clip también se están volviendo a renderizar con todo el subárbol volviéndose a renderizar dentro de los componentes de short clip. Con el compilador habilitado, gran parte del componente Video Player ha sido auto-memorizado y solo un cierto deslizador dentro de Video Player cambia o se vuelve a renderizar, porque ese valor particular cambió. Los componentes de short clip también han sido memorizados, pero este componente usa muchos componentes externos y esos no han sido memorizados, lo que lleva a algunas re-renderizaciones. Pero en general, diría que muchas de las re-renderizaciones han sido minimizadas y solo ciertos componentes importantes que realmente necesitan ser actualizados ahora se están volviendo a renderizar.

Ahora, todo esto se ve bien en DevTools, en papel, pero ¿cómo afecta realmente a nuestros usuarios reales? Entonces, lo que he notado es que con el compilador de React habilitado, hay un aumento insignificante en el tamaño del paquete. Ya estamos enviando bastante JavaScript. Simplemente habilitar el compilador no tuvo un aumento masivo en el tamaño del paquete, por lo que está bien enviar con el compilador de React habilitado. Los Web Vitals como FCP y LCP fueron casi los mismos, y la razón de esto es que todos los componentes deben renderizarse por la cantidad inicial, y ese no es el momento en que el compilador de React tiene sus beneficios. Podría haber un tiempo de paso ligeramente mayor es algo que siento debido al tipo de código que genera el compilador. Pero honestamente, esto no es algo de lo que debamos preocuparnos. El análisis de JavaScript es realmente rápido en todo tipo de dispositivos y navegadores hoy en día.

El mayor cambio que he notado es en la interacción con el siguiente core Web Vital de pintura. Este core Web Vital mide cuánto tiempo tarda en ocurrir la siguiente pintura cuando un usuario interactúa con algo en la página. Puedes medir esto usando la pestaña de rendimiento o Lighthouse durante el desarrollo, o puedes usar herramientas como Sentry o Postdoc para medir estos cambios en producción. Así que puedes ver si el valor INP disminuyó una vez que se habilitó el compilador. Ahora en Snagit, estos son los valores INP que vi al cambiar un deslizador particular en la aplicación. Así que los valores INP están alrededor de 45 milisegundos a 55 milisegundos. Y con el compilador habilitado, estos bajan a alrededor de 25 milisegundos. Así que fue una reducción del 44% en algunas partes de la aplicación.

Y ten en cuenta que ya había optimizado ciertos componentes sensibles al rendimiento en la aplicación. Así que si tienes una aplicación que tiene muchos componentes que no han sido optimizados, podrías ver ganancias mucho mayores. Con más cambios, pude lograr que el compilador optimizara 222 componentes, que es alrededor del 94% de los componentes en la base de código. Todavía hay un par de problemas que tengo en ciertos componentes. Hay una regla en React que dice no uses refs durante la renderización. Los estoy usando en algunos de mis componentes para ciertas optimizaciones. Y es por eso que algunos de los componentes están siendo omitidos por el compilador, lo cual está totalmente bien. Recuerda, no tienes que optimizar el 100% de la aplicación desde el principio. Puedes optimizar solo aquellos componentes que realmente están causando problemas y aumentar lentamente la cobertura con el tiempo.