React Compiler Internals

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

React Compiler fue introducido en 2024 como una forma de manejar automáticamente las optimizaciones de rendimiento en tus aplicaciones—pero, ¿cómo funciona? 

En esta charla, te guiaré a través de algunos de los aspectos internos de React Compiler. Exploraremos su proceso completo, desde el análisis hasta la transformación del Abstract Syntax Tree (AST), junto con sus tecnologías clave, beneficios, compensaciones y un ejemplo práctico de cómo transforma tu código para prevenir re-renderizados innecesarios.

La buena noticia: (afortunadamente) no necesitas dominar sus aspectos internos para integrarlo en tu base de código. Dicho esto, un sólido entendimiento de sus aspectos internos mejorará significativamente tu capacidad para aplicar las técnicas de optimización que desbloquea.

This talk has been presented at React Summit 2025, check out the latest edition of this React Conference.

Lydia Hallie
Lydia Hallie
23 min
13 Jun, 2025

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Introducción al React Compiler, sus beneficios y el problema de la memoización en React. Problemas de rendimiento debido a componentes con estado en React, solución con React.memo y use memo, y los beneficios del React Compiler en la automatización de la memoización. La transformación del compilador en una representación intermedia de alto nivel proporciona una comprensión más clara de las operaciones del código y el flujo de datos, abordando los problemas con identificadores únicos para variables en escenarios complejos. El compilador asegura que cada variable se asigne exactamente una vez a través de la asignación estática única, resolviendo problemas con los valores de las variables basados en rutas de código e introduciendo nombres únicos para las asignaciones. Los efectos describen cómo las operaciones interactúan con los datos, asegurando un almacenamiento en caché seguro con tipos como efectos de lectura, almacenamiento, captura, mutación y congelación. El compilador entiende las operaciones pero necesita identificar los valores que cambian entre renderizados para React, llevando a la fase de análisis reactivo para determinar los valores reactivos en el componente. Las variables marcadas como reactivas para cambios potenciales entre renderizados se optimizan para el almacenamiento en caché. El compilador identifica dependencias para agrupar operaciones para un almacenamiento en caché eficiente. Se establecen ámbitos para almacenar en caché variables relacionadas juntas y asegurar una renderización eficiente y mejora del rendimiento en el código JavaScript final. El compilador configura espacios de caché para dependencias y salidas para optimizar el rendimiento. Los ámbitos funcionan independientemente para recalcularse en base a cambios, asegurando una memoización eficiente. React Compiler simplifica la memoización, proporcionando optimizaciones automáticas correctas sin carga manual, allanando el camino para un código enfocado en el rendimiento.
Available in English: React Compiler Internals

1. React Compiler and Memoization

Short description:

Introducción al React Compiler, sus beneficios y el problema de la memoización en React.

Oh, buenos días a todos. Espero que hayan tomado un café bien cargado esta mañana porque comenzaré hoy con los aspectos internos del React Compiler. El año pasado en React Conf, el equipo de meta presentó el React Compiler, que es una herramienta de tiempo de compilación que automáticamente añade memoización a tus componentes y también aplica las reglas de React. Pero la auto-memoización es personalmente lo que más me entusiasma porque esto significa que finalmente no tenemos que añadir manualmente use memo, use callback, o React.memo. En su lugar, podemos escribir código React limpio y simple como este y el React Compiler automáticamente lo transforma en código JavaScript altamente optimizado con lógica de caché que sería prácticamente imposible de lograr manualmente.

Y lo bueno es que nunca tenemos que ver o mantener este código. Todo lo que tenemos que hacer es instalar el compilador, configurarlo con nuestra línea de compilación, pero ¿qué exactamente sucede detrás de escena para convertir nuestro código React simple en este código más optimizado? Bueno, hay muchas, muchas fases por las que pasa nuestro código en la línea de compilación. También puedes ver todas estas fases en los playgrounds de React Compiler si alguna vez has trabajado con eso. Demasiadas para mencionar en 25 minutos, así que en esta charla solo quiero repasar algunas de ellas, las más importantes.

Pero antes de entrar en el compilador, primero quiero centrarme en el problema que está resolviendo porque ¿por qué necesitamos siquiera memoización en React? Bueno, tomemos este código, por ejemplo. Así que tenemos un array con algunos usuarios, tenemos un componente de estadísticas de usuario que filtra los usuarios para encontrar cuáles están activos, y muestra los conteos. Y luego también tenemos un componente principal de la aplicación que muestra el conteo de usuarios activos y una forma de ordenar los usuarios en la lista. Claramente es un código de demostración, sé que esto no es muy de producción, pero cumple su función por hoy.

2. React Performance Optimization

Short description:

Problemas de rendimiento debido a componentes con estado en React, solución con React.memo y use memo, y los beneficios del React Compiler en la automatización de la memoización.

Ahora, hay un problema de rendimiento bastante grande en este código porque nuestro componente app es stateful. Tenemos un estado de sort que podemos cambiar de ascendente a descendente. Pero cada vez que actualizamos el estado, por ejemplo, en user sort, el componente app se vuelve a renderizar. Y por defecto, como sabemos, en React, cuando un componente se vuelve a renderizar, también lo hacen los componentes hijos. Así que esto significa que cada vez que cambiamos sort, user stats también se vuelve a renderizar, y este componente de función se vuelve a ejecutar. Pero dentro de user stats, estamos filtrando el array de users. Ahora, esto no es un gran problema si solo tenemos estos tres users, pero si tuviéramos 10,000 users, esto tiene implicaciones de rendimiento importantes.

Así que antes de que cualquier cosa pueda renderizarse, primero tiene que filtrar todos estos users. Pero el problema es que el array de users ni siquiera ha cambiado. Simplemente se está volviendo a renderizar porque sort cambió. Así que es completamente innecesario que esto se vuelva a renderizar. Para evitar esto, o para evitar esta re-renderización, podríamos envolver este componente en un React.memo. Y esto simplemente le dice a React que solo queremos volver a renderizar este componente si los valores de las props han cambiado. Así que en este caso, el array de users. Ahora también podríamos ser un poco más específicos y decir que solo queremos evitar que la función filter se vuelva a ejecutar en cada renderizado, y luego simplemente envolverla en un use memo en su lugar.

Y en ese caso, solo volvemos a ejecutar esta función filter cada vez que users cambie. Pero este enfoque tiene algunas desventajas. Porque ahora digamos que también queremos filtrar los users según su departamento. Bueno, ahora no podemos olvidar agregar también el valor de department a este array de dependencias. Si olvidamos agregar esto, el valor de active users no se actualizará cada vez que department cambie. Y este es un error que todavía cometo con bastante frecuencia, y este es como el mayor inconveniente de use memo. Así que esto es exactamente lo que el React Compiler resuelve.

3. Compiler Optimization Process

Short description:

La transformación del compilador en una representación intermedia de alto nivel proporciona una comprensión más clara de las operaciones del código y el flujo de datos, abordando los problemas con identificadores únicos para variables en escenarios complejos.

En lugar de tener que identificar manualmente estos cálculos costosos, envolverlos en un use memo, y tener que recordar este array de dependencias, el compilador se encarga automáticamente de memoizar esto por ti. Pero, ¿cómo es capaz de hacer esto? Bueno, ya viste todas estas fases, pero solo quiero hablar de algunas de las más importantes. Comenzando con la representación intermedia de alto nivel. Así que lo primero que hace el compilador es transformar el código en lo que se llama una representación intermedia de alto nivel, o HIR por sus siglas en inglés. Y mientras escribimos nuestro componente de función como un solo bloque de código, el compilador necesita ver cada operación por separado para realmente entender qué está pasando en tu código y también qué partes se pueden optimizar. Así que puedes ver que cada uno de estos pasos se representa como instrucciones individuales con un ID único, un valor donde se almacenan, y también la operación real.

Así que cuando miramos nuestro componente de función, el compilador ve que primero desestructuramos el parámetro user, luego cargamos esta variable user de la memoria, accedemos al método filter, creamos la función de callback del filter, luego dentro de la función de callback, cargamos el parámetro. Entiendes el punto. Lo ve a un nivel muy granular, atómico. Así que ahora el compilador tiene una imagen mucho más clara de cada operación individual, pero especialmente de cómo fluye la data dentro del código. Por ejemplo, ahora podemos ver que la instrucción 13 devuelve la variable 19, que contiene el JSX creado en la instrucción 12, y este elemento JSX, a su vez, combina el texto de la variable 17 y el valor dinámico de count. Así que todos estos están conectados.

Y de la misma manera, la instrucción 9 carga el valor de la variable 14, que a su vez usa el valor almacenado en 13 para acceder al enlace. Así que al transformar nuestro JavaScript en este HIR, esta representación intermedia de alto nivel, el compilador ahora tiene una imagen mucho más clara de cada operación que ocurre y de cómo fluye la data. Pero todavía hay un problema con la forma en que está escrito actualmente. Podrías notar que cada variable tiene un identificador único. Sabes, tenemos users 1, active users 11, count 15, y así sucesivamente. Y esto funciona bien en el ejemplo simple que acabo de usar, pero ahora si miramos un ejemplo más complejo, digamos que ahora también estamos pasando una prop filters que tiene una propiedad limit results en ella, y luego reasignamos condicionalmente active users basado en si el usuario quiere limitar los resultados.

4. Single Static Assignment in Compiler

Short description:

El compilador asegura que cada variable se asigne exactamente una vez a través de la asignación estática única, resolviendo problemas con los valores de las variables basados en rutas de código e introduciendo nombres únicos para las asignaciones.

Ahora el HIR se ve así, lo cual es un poco más intimidante, pero lo que importa aquí es que estamos ordenando el usuario activo o almacenando la variable de usuarios activos aquí, cargamos la prop filters, accedemos a la propiedad limit results en filters, y ahora finalmente llegamos a la declaración if, y esto es un condicional. Ahora en esta línea, esencialmente dice que si filters.limit results es verdadero, entonces ejecuta el bloque 4, que es el bloque con un método slice. De lo contrario, simplemente ve directamente al bloque 3. Ahora el problema aquí es que el usuario activo o es la variable de usuarios activos. Así que puedes ver aquí que estamos usando la misma variable de usuarios activos, usuarios activos 12, múltiples veces en este código. Pero el problema es que la misma variable ahora se refiere a diferentes valores dependiendo de qué ruta de código tomamos. Si venimos directamente del primer bloque, entonces cuando limit results es falso, entonces usuarios activos solo contiene el array filtrado. Pero si venimos del tercer bloque, cuando limit results es verdadero, ahora contiene el array filtrado y cortado.

Así que el compilador ahora no puede saber en tiempo de compilación qué podría seleccionar el usuario. Podría ser verdadero, podría ser falso. Así que con el HIR actual, el compilador no puede optimizar de manera segura el valor de usuarios activos. Así que aquí es donde entra la siguiente fase, la asignación estática única, o SSA. La asignación estática única es una forma dentro del HIR que asegura que cada variable se asigne exactamente una vez. Así que ahora puedes ver que cada asignación obtiene un nombre de variable único. Tenemos usuarios activos 42 para el método filter y usuarios activos 52 para la operación slice. Pero nota que ambos conducen al tercer bloque. Y el tercer bloque es donde estos dos caminos de código se juntan. Así que ahora si venimos del segundo bloque, o tenemos una función aquí que dice que si venimos del segundo bloque entonces usa usuarios activos 52, pero si venimos del tercer bloque, si limit results es verdadero, entonces usa 42, que es el filtrado y el cortado.

Ahora de nuevo, en nuestro fragmento de código original, esto no era un problema. No teníamos reasignaciones de variables que pudieran crear este tipo de declaración de variable ambigua. Así que en ese caso, la transformación SSA todavía ocurre, pero es más directa. Cada variable todavía obtiene un nombre único. Pero mucho más simple en este caso. Solo quería mostrarlo porque a lo largo del resto de la demostración, verás los otros nombres de variables, así que solo quería que supieras que esto sucedió. Así que ahora tenemos nuestro flujo de datos bastante claramente mapeado, pero el compilador todavía necesita entender dos cosas críticas. Los tipos de datos con los que estamos trabajando, y también lo que cada operación realmente hace a esos datos. Así que primero tenemos la inferencia de tipos, y esto es bastante fácil. Aquí el compilador determina si los valores son primitivos, objetos, funciones, elementos de React, y así sucesivamente. Pero ahora también necesita determinar cómo estas operaciones interactúan con los datos.

5. Compiler Effect Analysis and Reactive Detection

Short description:

Los efectos describen cómo las operaciones interactúan con los datos, asegurando un almacenamiento en caché seguro con tipos como efectos de lectura, almacenamiento, captura, mutación y congelación. El compilador entiende las operaciones pero necesita identificar los valores que cambian entre renders para React, llevando a la fase de análisis reactivo para determinar los valores reactivos en el componente.

Y un efecto simplemente describe cómo una operación interactúa con los datos, ya sea que los lea, los cambie, los modifique, y así sucesivamente. Y esto es realmente importante más adelante para la memorización, porque un compilador necesita saber qué operaciones son seguras para almacenar en caché, y cuáles podrían romperse si se almacenan incorrectamente. Así que hay seis tipos de efectos. Así que en nuestro caso, primero tenemos algunos efectos de lectura, como acceder a un método como filter o length. Así que un efecto de lectura no cambia nada del código. Así que cualquier efecto de lectura es perfectamente seguro para almacenar en caché. También tenemos algunos efectos de almacenamiento, y estos son efectos de almacenamiento donde asignamos nuevos valores. Así que estos son seguros para almacenar en caché, siempre que el valor que se está almacenando no dependa de ningún dato mutable. Ahora también tenemos eventos de captura, y estos son eventos para cargar valores desde un ámbito externo. Así que parámetros de función o variables almacenadas previamente. Y estos crean dependencias que el compilador necesita rastrear para tener la memorización correcta. También tenemos efectos de mutación. Estas son operaciones que podrían modificar dependiendo de lo que suceda en tiempo de ejecución, y eso es la mayoría de ellas. Por último, también tenemos efectos de congelación, y estos hacen que los valores sean inmutables, por lo que garantizan que no puedan ser modificados más tarde. Y el compilador simplemente agrega estos para asegurarse de que los datos no cambien, haciéndolos seguros para almacenar en caché.

Bien. Así que finalmente en este punto, el compilador ahora entiende lo que hace cada operación y cómo afecta a los datos. Pero aún no sabe qué valores cambian entre renders. Así que, por ejemplo, sabemos que la instrucción tres tiene un efecto de lectura al acceder a filter, pero eso no nos dice si el array de usuarios puede cambiar entre renders. Tal vez siempre sea el mismo array estático, tal vez venga de props o state y así sucesivamente. Así que el análisis de efectos nos dice el potencial de cambio, pero no nos dice si realmente cambiará o el cambio que realmente importa en React, si puede cambiar entre re-renders. Así que ahora es el momento de la siguiente fase, el análisis reactivo. Así que durante esta fase, el compilador tiene que averiguar qué valores específicos en este componente son reactivos, lo que significa que pueden cambiar entre renders. Así que solo para hacer el código un poco más legible, simplemente eliminaré los tipos, porque de lo contrario tendría que hacer la fuente realmente pequeña, pero todavía están ahí. Así que el compilador primero comienza mirando la fuente de cada valor, y para verificar si es reactivo, comienza con los valores que son definitivamente reactivos, que son los parámetros de función que siempre son reactivos, porque vienen de props, siempre pueden cambiar entre renders, y también las llamadas a hooks producen valores reactivos, como use state, use context, pero en este caso solo tenemos parámetros de función. Así que ahora el parámetro de función está marcado como reactivo, pero luego sigue adelante a través del flujo de datos con una regla simple. Si un valor reactivo fluye hacia una operación, esta salida también se vuelve reactiva. Y lo que esto significa es, mirando nuestro ejemplo, el parámetro de usuarios comienza como reactivo, porque es un parámetro de función, pero ahora tenemos un valor reactivo, 23 también se vuelve reactivo, y luego cargamos usuarios en la línea dos, así que 24 también se vuelve reactivo.

6. Compiler Scope Discovery and Code Generation

Short description:

Las variables marcadas como reactivas para cambios potenciales entre renders están optimizadas para el almacenamiento en caché. El compilador identifica dependencias para agrupar operaciones para un almacenamiento en caché eficiente. Se establecen ámbitos para almacenar en caché variables relacionadas juntas y asegurar una renderización eficiente y mejora del rendimiento en el código JavaScript final.

Entonces, para ampliar un poco, ¿qué estamos realmente viendo aquí? Bueno, realmente lo que estamos diciendo aquí es que para la estructuración inicial de propiedades, creamos una nueva vinculación, pero esto es, por supuesto, reactivo, esta prop puede cambiar entre renders, y eso es lo que dice este HDR actual. Luego cargamos usuarios 22 en esta nueva variable temporal 24, esto también es reactivo, porque estamos leyendo la variable reactiva usuarios 22, por lo que el valor de esta cosa atómica específica en nuestra función puede cambiar entre renders. Ahora, acceder al método filter aquí también puede cambiar entre renders, porque si estamos trabajando con un nuevo array de usuarios, y los arrays son objetos, lo que significa un objeto completamente nuevo, este método filter estaría en un objeto completamente nuevo, por lo que esto también puede cambiar entre renders. Así que nuevamente, esta fase asegura que cada valor que podría cambiar entre renders se marque como reactivo. Y estos valores reactivos son exactamente lo que el compilador quiere optimizar. No tiene sentido memorizar algo que nunca cambia, pero los valores que pueden cambiar entre renders son perfectos para el almacenamiento en caché. Así que ahora el compilador conoce tanto el comportamiento de las operaciones a partir de los efectos, como también qué valores realmente importan para el renderizado reactivo para el análisis reactivo.

Bien, así que en este punto, tenemos nuestro código desglosado en un HDR, tipos, efectos, y así sucesivamente, y también sabemos qué valores pueden cambiar entre renders. Ahora el compilador tiene que decidir qué operaciones deben almacenarse en caché juntas, y cuáles deben ejecutarse cada vez. Las variables que cambian juntas también deben almacenarse en caché juntas. Así que ahora es el momento de la siguiente fase que es el descubrimiento de ámbitos. Así que ahora el compilador tiene que decidir qué operaciones deben almacenarse en caché juntas, pero la idea es que las variables que cambian juntas deben almacenarse en caché juntas, y las variables que cambian independientemente deben almacenarse en caché independientemente. Así que durante esta fase, el compilador agrupa la operación en función de sus dependencias, por lo que las operaciones que dependen de las mismas entradas se agrupan en el mismo ámbito. Así que después del descubrimiento de ámbitos, nuestro HDR ahora se ve algo así donde tenemos tres ámbitos. Primero, tenemos el ámbito cero que son solo las funciones de callback porque las funciones obtienen su propio ámbito porque pueden memorizarse independientemente porque no dependen de ningún valor reactivo, por lo que esto puede almacenarse en caché una vez y luego reutilizarse en todos los renders prácticamente. Ahora el ámbito uno cubre las instrucciones tres, cinco y seis, y todas dependen de la entrada del usuario para estas operaciones de filtrado. Todas necesitan recalcularse cada vez que el array de usuarios cambia, por lo que todas se agrupan.

Así que ampliando, toda esta operación de filtrado ahora se convierte en su propio ámbito memorizable. Esto es casi como lo que teníamos con useMemo, pero ahora se hace automáticamente por el compilador. Y el callback de filters también se extrae completamente porque esto no depende de nada y esto podría simplemente reutilizarse en todos los renders. Incluso obtenemos un ámbito separado para la creación de JSX, por lo que esto solo se recalcula cada vez que count cambia. Así que si el array de usuarios cambia pero la cantidad total de usuarios es la misma, entonces podemos simplemente reutilizar este JSX almacenado en caché, y esto es algo que es prácticamente imposible de hacer con useMemo pero se hace automáticamente con el compilador. Después de obtener su propio ámbito, la función de callback ahora se convierte en una función separada. Así que la lógica sigue siendo exactamente la misma pero es solo su propio bloque, y esto es genial porque no tenemos que crear un nuevo objeto de función ahora en cada render. Así que el compilador identifica automáticamente estas como funciones puras y las extrae lo que es un mejor rendimiento que veremos en el resultado final también. Así que en este punto los ámbitos simplemente existen como anotaciones en nuestro HDR pero necesitan convertirse en fuentes de flujo de control reales para la generación de código. Así que el compilador ahora estructura el ámbito en una presentación diferente que muestra claramente qué instrucciones pertenecen a cada ámbito y también cuáles son sus dependencias y salidas. Así que ahora puedes ver claramente que el ámbito uno depende de la variable de usuarios y produce el resultado del filtro mientras que el ámbito dos depende de count y produce este JSX. Así que este flujo de control explícito ahora es muy importante para la siguiente fase, finalmente llegamos a la generación de código. Así que esto convierte nuestro HDR en el JavaScript optimizado que vimos desde el principio.

7. Compiler Memoization Optimization

Short description:

El compilador configura ranuras de caché para dependencias y salidas para optimizar el rendimiento. Los ámbitos funcionan de manera independiente para recalcularse según los cambios, asegurando una memorización eficiente. El React Compiler simplifica la memorización, proporcionando optimizaciones automáticas correctas sin carga manual, allanando el camino para un código enfocado en el rendimiento.

Para hacer esto, el compilador primero recorre cada ámbito y configura ranuras de caché, por lo que necesitamos dos tipos de ranuras aquí, una ranura para cada dependencia para que podamos detectar los cambios y también una ranura para cada valor de salida para que realmente podamos almacenar en caché el resultado. Así que en total obtenemos cuatro ranuras ahora porque tenemos la dependencia users con la salida y luego también tenemos las dependencias count con la salida JSX. Ahora esto genera automáticamente una llamada de caché use memo pero usualmente en tu código de React Compiler solo verás esto como un lower, como se llame, low-C porque eso es simplemente más corto para propósitos de empaquetado, supongo. Así que luego genera el resto del código, que ahora incluye nuestro parámetro de usuario desestructurado, luego tenemos nuestro primer ámbito, y podemos ver aquí que primero verifica si los usuarios han cambiado desde la última vez comparándolo con lo que está almacenado en nuestra ranura de caché cero. Si es así, entonces por supuesto ejecuta esta operación de filtro costosa y almacena tanto la nueva referencia de usuarios como el resultado T1 en el caché y si no, simplemente usa el resultado anterior de la ranura de caché uno. Luego tenemos estos valores no agrupados que simplemente se ejecutan cada vez, como asignar el resultado del filtro a active users y calcular los counts, y finalmente también tenemos el segundo bloque de caché para la creación de JSX. Si el valor de count es diferente al de la última vez, crea un nuevo JSX y actualiza el caché y de lo contrario simplemente reutiliza este JSX en caché. Eventualmente devolvemos T2 y ese es el JSX con la variable count. La parte agradable aquí es que todos estos ámbitos funcionan de manera independiente, por lo que si el array de usuarios ha cambiado, el primer ámbito se recalcula, pero si la longitud de la cantidad total de usuarios no ha cambiado, entonces no hay necesidad de generar un nuevo JSX, simplemente podemos obtener el almacenado. Hacer esto de manera específica con use memo significaría que tendríamos que crear pequeñas piezas de envoltura en todo nuestro código, y técnicamente podrías hacerlo pero sería una pesadilla de mantenimiento, pero el compilador hace todo esto automáticamente.

Finalmente hemos completado todas las fases, desde HIR, SSA, inferencia de tipos, análisis de efectos, descubrimiento de ámbitos hasta la generación de código. Es importante entender que React Compiler no es una bala de plata. El compilador no puede optimizar el código que rompe las reglas de React, como llamar condicionalmente hooks, componentes con efectos secundarios que no pueden ser almacenados en caché de manera segura, cosas heredadas como componentes de clase y algunos patrones de JavaScript más complejos que el compilador simplemente no puede resolver de manera segura. El compilador siempre intentará no memorizar nada si no está seguro. Mejor prevenir que lamentar. Si tu aplicación ya está bien optimizada con muchas memorizaciones manuales, no deberías esperar una gran mejora en el rendimiento porque la verdadera ganancia aquí son las optimizaciones automáticas correctas sin la carga de mantenimiento. No significa necesariamente que siempre sea mejor rendimiento que usar manualmente use memo. Si estás interesado en verificar qué tan lista está tu base de código existente para React Compiler, puedes simplemente ejecutar este comando, que analiza tu proyecto e identifica componentes que rompen las reglas de React o te muestra posibles problemas de compatibilidad. A partir de hoy, el compilador se ha movido al candidato de lanzamiento y se está preparando para su lanzamiento estable, pero ya puedes probarlo hoy en frameworks como Expo o Next.js simplemente instalando el plugin de Babel y agregándolo a tu aplicación. Si lo has habilitado en tu aplicación, puedes verlo funcionando en React DevTools con todos estos memos brillantes, estos son memorizados automáticamente por React Compiler. Así que con React Compiler, ya no tenemos que elegir entre escribir código limpio y también tener código de rendimiento. Así que el compilador maneja automáticamente toda esta memorización por nosotros. Y esto es prácticamente el futuro de React, es simplemente rendimiento por defecto pero sin la complejidad, y esto es exactamente lo que habilita el compilador.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
If You Were a React Compiler
React Summit US 2024React Summit US 2024
26 min
If You Were a React Compiler
Top Content
In this talk, the speaker aims to build an accurate understanding of how the new React compiler works, focusing on minimizing re-renders and improving performance. They discuss the concept of memoization and how it can be used to optimize React applications by storing the results of function calls. The React compiler automates this process by analyzing code, checking dependencies, and transpiling JSX. The speaker emphasizes the importance of being aware of memory concerns when using memoization and explains how the React compiler detects changes in function closure values. They also mention the Fibre Tree, which drives the reconciliation process and helps optimize performance in React. Additionally, the speaker touches on JSX transpilation, compiler caching, and the generation of code. They encourage developers to understand the code generated by the compiler to optimize specific sections as needed.
Todo lo que necesitas saber sobre React 19
React Summit US 2024React Summit US 2024
29 min
Todo lo que necesitas saber sobre React 19
React 19 introduces new features such as React Compiler and React Actions, which optimize code and provide better performance. The useOptimistic hook allows for optimistically updating UI, while the UseFormStatus hook tracks loading states and enables button disabling. The introduction of the 'action' attribute simplifies form handling and data retrieval. React 19 eliminates the need for useMemo and useCallback thanks to the React Compiler. The stability of React 19 has been observed in side projects without major issues.
What Refs Can Do for You
React Summit US 2024React Summit US 2024
27 min
What Refs Can Do for You
Today's Talk focused on using refs and profiling Agigrid in React. The speaker shared their experience with optimizing custom cell components and performance, including using memo and leveraging the React compiler. They also discussed improving performance with manual style updates and refactoring the use of useEffect. The speaker highlighted the use of ref callbacks, which can be implemented with useLayoutEffect. React 19 introduces changes to the ref callback approach. The Talk touched on using React DevTools and CSS variables for monitoring renders. It also discussed the compatibility of Azure Grid with React and the trade-offs between using React components and vanilla JavaScript. The speaker emphasized the importance of considering the DX improvements and the complexity of not seeing a React component tree in the dev tools. The Talk concluded with a mention of AG Grid features, handling refs at various levels, and the recommendation to consult with Stephen for technical questions and application architecture.
React 19 y el compilador para el resto de nosotros
React Day Berlin 2024React Day Berlin 2024
30 min
React 19 y el compilador para el resto de nosotros
Hi everyone. I'm Johnny, an application engineer who builds user-centric React 19 applications. Today, our goal is to help you reach production mountain with React 19. Let's start by gathering a crew and discussing the motives for installing the compiler. We'll revisit React rules and explore the compiler's impact on code. The React compiler translates from JavaScript to JavaScript and provides error reporting. It enables deeper levels of optimization and focuses on user experience. To upgrade to React 19, install the latest version and be aware of any compatibility issues. Check if any custom runtime code needs to be disabled. The React compiler can be used with versions 17 or 18 if you have runtime support. The compiler removes use memos and optimizes the initialization process based on static components. It provides granular reactivity and reduces rendering, making the application feel quicker. Follow React rules and conventions to ensure compatibility. Test custom hooks, be aware of the impact on build time, and address any unexpected issues like the removal of the global JSX namespace. Debugging tools and source mapping in Chrome are useful for understanding compiler output. Enjoy translating chants and exploring the possibilities of React 19!
Guía para Desarrolladores de Aplicaciones sobre React 19: Lo que Necesitas Saber y Todo lo que Puedes Ignorar con Seguridad
React Summit US 2024React Summit US 2024
33 min
Guía para Desarrolladores de Aplicaciones sobre React 19: Lo que Necesitas Saber y Todo lo que Puedes Ignorar con Seguridad
Today's Talk focused on React 19 and its features, APIs, changes, and optimizations. The speaker emphasized the importance of migrating apps and building with React 19. They discussed the high-level features of React 19, including TypeScript emphasis and the testing library philosophy. The Talk also covered the APIs and integration of React 19, as well as the changes and type safety it brings. The speaker highlighted the improvements in useReducer types and the use of TypeScript. They introduced useActionState for migrating code and the useOptimistic hook for maintaining state immediacy. Real-time updates, action functions outside components, and the benefits of using the 'use' prefix in React were also discussed. The Talk touched on upgrade considerations, the role of RSEs and server actions in React, and the current state of RSC development. Overall, the Talk provided valuable insights into the new features and enhancements in React 19 and their impact on the development process.

Workshops on related topic

Dominando React Server Components y Server Actions en React 19
React Advanced 2024React Advanced 2024
160 min
Dominando React Server Components y Server Actions en React 19
Workshop
Maurice de Beijer
Maurice de Beijer
¡Llamando a todos los desarrolladores de React! Únete a nosotros para una inmersiva masterclass de 4 horas profundizando en React Server Components y Server Actions. Descubre cómo estas tecnologías revolucionarias están transformando el desarrollo web y aprende a aprovechar su máximo potencial para construir aplicaciones rápidas y eficientes.
Explora el mundo de React Server Components, combinando sin problemas el renderizado del lado del servidor con la interactividad del lado del cliente para un rendimiento y experiencia de usuario incomparables. Sumérgete en React Server Actions para ver cómo combinan la interactividad del lado del cliente con la lógica del lado del servidor, facilitando el desarrollo de aplicaciones interactivas sin las limitaciones tradicionales de API.
Obtén experiencia práctica con ejercicios prácticos, ejemplos del mundo real y orientación experta sobre la implementación de estas tecnologías en tus proyectos. Aprende temas esenciales como las diferencias entre Server y Client Components, optimización de la obtención de datos, pasando datos de manera efectiva y maximizando el rendimiento con nuevos hooks de React como useActionState, useFormStatus y useOptimistic.
Ya sea que seas nuevo en React o un profesional experimentado, esta masterclass te equipará con el conocimiento y las herramientas para elevar tus habilidades de desarrollo web. Mantente a la vanguardia y domina la tecnología de vanguardia de React 19. No te lo pierdas: regístrate ahora y desata todo el poder de React!
Evolución de la Gestión de Formularios en React
React Summit US 2024React Summit US 2024
72 min
Evolución de la Gestión de Formularios en React
Workshop
Adrian Hajdin
Adrian Hajdin
Aprende cómo manejar formularios en React utilizando las últimas características, como startTransition, useTransition, useOptimistic y useActionState, con y sin acciones del servidor de React 19, junto con la validación adecuada, manejo de errores y mejores prácticas.La masterclass comenzará demostrando el manejo tradicional de formularios usando useState y useEffect para el renderizado del lado del cliente. Gradualmente, pasaremos a utilizar las últimas características de React 19, incluyendo formularios del lado del servidor y los hooks más recientes para gestionar estados y errores de formularios. Al final de la masterclass, los participantes entenderán cómo crear formularios robustos con validación adecuada y manejo de errores.Objetivos de AprendizajeÚltimos Hooks de React 19 — useTransition, useFormStatus, useOptimistic, useActionState, useDeferredValueAcciones del ServidorRevalidacionesValidación del lado del ServidorManejo de ErroresPrácticas de Seguridad