React Compiler Internals

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.

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.

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.

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.

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.

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.

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.