How to React Compiler

Hola a todos, y bienvenidos a mi charla sobre el compilador de React. Mi nombre es Anton Nevsha, y permítanme presentarme rápidamente antes de sumergirnos en el mundo del compilador de React. Tengo 11 años de experiencia comercial como ingeniero de front-end, y eventos y conferencias como React Summit son realmente lo que me inspira y mejora mi vida. Así que, sí, realmente estoy contento de estar aquí con ustedes hoy.

En mi carrera, desarrollo aplicaciones de banca en línea, y algunas de ellas están realmente en producción, trabajando en el compilador de React. Así que, realmente quería compartir con ustedes mi experiencia con la adopción de esta tecnología, de esta herramienta. Y permítanme comenzar diciendo que el compilador de React no es lo mismo que React 19, ¿verdad? Así que, para algunos de nosotros que todavía estamos familiarizándonos con la tecnología, vale la pena señalar que solo instalar React 19 no les dará el beneficio de esas memorizaciones automáticas y otras características que el compilador de React tiene para ofrecer.

Así que, necesitaríamos instalar otro paquete llamado complemento Babel para el compilador de React, que es un paquete separado de NPM. Y esto es bastante sencillo de configurar e instalar, porque todo lo que tenemos que hacer es especificar el nombre del complemento en nuestro archivo de configuración V, y estamos listos para comenzar. Otra cosa es que también podemos especificar la versión objetivo de React si estamos trabajando con versiones anteriores de React, digamos 17 o 18. Y configurarlo de esta manera nos daría este resultado. Este es el archivo de salida, y el componente de entrada y el componente de salida que se procesa con el compilador de React. Lo que básicamente hace es detectar las props o variables de las que depende nuestro componente, y basado en su comportamiento, si cambian o no, volvería a calcular la salida del componente o simplemente devolvería la salida precomputada del componente.

Y eso es básicamente todo. Pero lo interesante de esto es que, si configuramos nuestro compilador de React de esta manera, colocando este pequeño objeto de configuración en el archivo de configuración del plugin, terminaríamos teniendo tantas configuraciones, y tantas opciones y configuraciones. Esas son las opciones predeterminadas que el compilador de React tiene para ofrecer, y deberíamos tener cuidado con ellas, porque algunas de ellas son directas, pero otras, como esta clave de environment, básicamente contiene un objeto con 30 o 30 y tantas otras configuraciones y opciones.

Y si quieres ver lo que está haciendo y ver cuáles son, el mejor lugar para referirse es en realidad el sitio web de playground del compilador de React. Y aquí en el lado derecho, está esta sección de configuración de environment, que es expandible, y nadie realmente habla de ella por alguna razón. Nunca. Pero este es el mejor lugar para averiguar qué configuración es mejor para tu proyecto, básicamente. Y aquí en el lado izquierdo, está el componente de muestra que estoy usando.

Este es el tipo de componentes que todos hemos visto. Está esta función de lista que acepta un array de people, y el problema es que tenemos que iterar sobre cada elemento dentro de este array para crear algún tipo de marcado JSX. Y no es gran cosa, ¿verdad? Pero el hecho es que cada vez que cualquiera de los elementos dentro del array cambia, o si, digamos, añadimos más elementos al array, todavía tendríamos que volver a calcular todos los elementos dentro de este array una vez más. Y normalmente, antes del compilador de React, terminaríamos extrayendo esta parte de JSX en un componente separado y también envolviéndolo en react.memo, solo para asegurarnos de que no volveríamos a calcular esos elementos nuevamente.

Y la parte brillante del compilador de React es que en realidad tiene la misma característica de extraer la parte JSX de las devoluciones de llamada del método map de un array. Puede hacer esto automáticamente por nosotros, y el problema es que la característica responsable de hacerlo está habilitada por defecto. Pero en este ejemplo, todavía no obtenemos la memorización automática. Todavía no vemos cómo se está extrayendo este JSX porque esta parte de JSX sigue siendo parte de la función más grande. No es una función separada. Bueno, ¿por qué es eso? Porque la opción enable function outlining aquí está configurada en true, y esta es la opción exacta que es responsable de extraerlo.

Bueno, la cosa es que esta característica de enable function outlining tiene sus propios límites. El problema particular aquí es que, en nuestros componentes, tenemos esta variable style definida, y el problema es que está declarada fuera del ámbito de la devolución de llamada del método map del array. Ves que está declarada fuera, y esto es algo que enable function outlining no puede tolerar y no puede trabajar con ello. Pero afortunadamente, todavía tenemos algunas soluciones alternativas con el environment, y también podemos habilitar otra característica llamada enable JSX outlining, que actualmente está configurada en false por defecto, pero podemos habilitarla fácilmente. Es un poco complicado en el sitio web de Playground porque esta parte derecha no es editable. No puedes escribir nada aquí. No puedes escribir nada ni cambiar nada aquí.

La única parte que es editable es esta parte izquierda. Entonces, ¿cómo habilitamos todas las banderas que queremos? Bueno, esto es realmente bastante simple. Solo tendríamos que agregar un comentario en algún lugar por encima de nuestra función y agregar una anotación correspondiente a la bandera que queremos habilitar. Esta anotación enable JSX outlining, que colocamos aquí, habilitaría la bandera de JSX outlining aquí, lo que, a su vez, cambiaría la salida del compilador de React. Y ahora puedes ver que tenemos una salida diferente, básicamente. Tenemos este const t0 igual a underscore temp, y esta función underscore temp es básicamente una función separada, absolutamente independiente de lo que teníamos antes. Y esta función se declara aquí debajo del componente anterior.

Y vemos que esta función en realidad parece un componente de React que está siendo memorizado de la misma manera que lo hace React.Memo. Así que, estas son buenas noticias, y esto es algo con lo que podemos trabajar. Genial.

Entonces, una cosa importante sobre el compilador de React es que mientras trabajaba con el compilador de React, todavía estaba en beta. Y cuando el proyecto está en beta, no es una sorpresa que algo pueda cambiar. Algo puede desarrollarse más. Algo puede no estar tan bien aún. Así que, para que no rompamos nada y para asegurarnos de que la integridad de nuestra aplicación no sufra, al menos deberíamos saber qué puede romperse.

Así que, estas son las cosas que pueden romperse con o sin el compilador de React. Estos son los mensajes de error que obtienes al trabajar con el compilador de React, y esos tres son bastante sencillos. Cuando tienes JS inválido o React inválido, no es una sorpresa que el compilador de React no lo maneje. No es específico del compilador de React. Esto es algo que ningún plugin de Babel toleraría y rompería. Si tienes una configuración válida, también puede resultar en una salida inválida. Pero hay algunas especificidades para el compilador de React, y algunas de ellas son bastante curiosas.

Una de ellas es to-do o invariant. Básicamente, son algunos errores internos del compilador de React que podrían indicarte que algo no está terminado aún con el desarrollo del propio compilador de React. Como ejemplo, puedo darte este componente. Siempre que tengas la variable llamada FBT declarada en algún lugar de tus componentes, ves que puede que ni siquiera quieras usarla. Pero solo el hecho de que tengas esta variable y tenga el nombre FBT hace que el compilador de React te arroje un error, diciendo que el soporte de las variables locales con el nombre FBT no está soportado aún.

Pero esto es solo algo divertido a tener en cuenta, y estoy seguro de que se va a solucionar pronto. Pero hay un error más importante con el que podrías encontrarte, que es que no puede preservar la memorización. Ahora, este error ocurre cuando el compilador de React no puede garantizarnos que el nivel de memorización que teníamos es el mismo después de que el compilador de React hace su trabajo. Así que, no está seguro si el nivel de memorización se mantiene igual. Y esto es un gran problema. Es una gran noticia que tengamos estos errores indicando que algunos de los componentes no están tan bien memorizados como solían estar.

Pero el hecho es que este mensaje de error está oculto por defecto. Si deseas ver esos mensajes de error, es posible que desees especificar la configuración del umbral de pánico en tu configuración del plugin, básicamente para que puedas ver qué componente no es soportado por el compilador de React y cuál está funcionando bien. Así que, por defecto, lo que hace el compilador de React es simplemente omitir el componente que no puede memorizar correctamente. Si deseas ver más información sobre eso, es posible que desees habilitar esta función. Y una cosa más útil es que hay esta bandera de entorno llamada validate preserve existing memorization guarantees.

Ahora, lo que hace es, en realidad, es responsable de arrojar ese error de que no puede preservar la memorización. Así que, si habilitas esta bandera validate preserve existing memorization guarantees, verás esos errores más a menudo, y verás más a menudo si algunos de los componentes no están siendo memorizados lo suficientemente bien. Esta bandera es recomendada por el equipo del compilador de React para ser habilitada cuando estás migrando tu base de código al compilador de React, pero está deshabilitada por defecto. Así que, asegúrate de habilitarla para ver qué está pasando con tu base de código. Lo que hace esta opción es, básicamente, darte errores cuando en algún lugar de tu base de código hay dependencias de hooks que se están usando mal, o algunas mutaciones de hooks en curso, o algunas otras reglas de React que se están rompiendo.

Hay más herramientas de validación y más opciones de validación que puedes especificar si lo deseas, pero también son directas y se explican por sí mismas. Como validate no set state in render, esto es claro lo que significa. Así que, puedes especificarlas si realmente las necesitas. Y hay algunas otras lecciones que he aprendido con React compiler al trabajar con él, y una de mis cosas favoritas es la forma en que React compiler trata los hooks.

Imaginemos que tenemos este componente de ejemplo que usa este hook useAccessibility. En realidad, no importa exactamente lo que hace, pero lo que importa es que es un useMemo. Si conocemos useMemo, es bastante directo. Simplemente recuerda las variables de dependencia y ejecuta la función si la dependencia cambia. Así que, tengo este console log aquí, pero estamos bastante seguros de que este console log no se ejecutaría si las dependencias de product o flag no cambian.

Pero, veamos qué está pasando con este componente y con este hook después de compilarlos con React compiler. Ahora, en cuanto al componente en sí, esto es bastante simple, en realidad. Todavía tenemos esta llamada al hook useAccessibility, y si es una llamada a un hook, no podemos colocarla dentro de una declaración if o dentro de un condicional. Así que, es básicamente donde pertenece. Es el nivel superior de la función, y se ejecuta cada vez que el componente se está renderizando. Pero, en cuanto al hook en sí, bueno, ahora vemos que este console log se está ejecutando mucho más a menudo, porque se está ejecutando incluso antes de que verifiquemos la dependencia de flag o product. Así que, esto es una especie de cambio en el comportamiento y cambia la forma en que memorizamos las cosas, y hay varias maneras de lidiar con eso.

Lo primero que puede ayudarnos es simplemente cambiar la forma en que trabajamos con hooks y simplemente renombrarlos y deshacernos del hook en sí. Digamos que tenemos el hook useAccessibility, y deberíamos convertirlo en una función getAccessibility que no funcionará como un hook, y no cumplirá con las convenciones de nomenclatura del hook, y no será compilada por React compiler. Imagina lo que teníamos antes. Teníamos este hook useAccessibility ejecutado cada vez. Pero, si tuviéramos la función getAccessibility, sería bastante normal simplemente colocarla dentro de la declaración if, manteniendo así el mismo nivel de memorización que teníamos antes.

Esta es una gran noticia, y otro ejemplo de cómo podemos hacer esto es simplemente usar esas declaraciones como useNoMemo o useNoForget. Esas declaraciones le dirían a React compiler que omita el componente o el hook, y permanecerá igual que solía ser. Esta es también la forma de mantener el mismo nivel de memorización. Otra solución es simplemente no mantener esta lógica en la capa de vista. Puedes simplemente colocarla en algún lugar en tu gestor de estado, o en algún lugar por encima de la capa de React, en algún lugar así.

Hablemos también de los valores de retorno de los hooks. Deberían ser mutables, ya que es una regla de React, y, al trabajar con ellos, imagina este ejemplo donde tenemos esta variable status key, que es el resultado de la llamada useMemo. Cada vez que la pasamos a alguna función, aunque esta función podría no mutar exactamente esto, como esta función de traducción de internacionalización, que no muta la clave, solo la acepta. Pero aún así, React compiler no estaría contento con eso. Nos lanzaría un error, porque básicamente violamos la regla de React de mutar este valor de retorno del hook. Lo que podemos hacer con eso es simplemente reorganizar un poco la estructura del proyecto, o podemos desactivar la bandera de entorno que te mencioné antes, validate preserve existing memorization guarantees.

Si lo configuramos en false, no reaccionará a esas situaciones, aunque sea una violación de la regla de React, y debería reaccionar a eso. O, simplemente puedes deshacerte de useMemo, porque este es un ejemplo clásico de simplemente eliminar completamente el useMemo, y tener la misma salida que antes, porque esto es lo que obtendríamos. Esto es lo mismo que usar useMemo.

Así que, tenemos esta función getStatusKey que se ejecuta solo si la variable entity cambia. Esto es exactamente lo que necesitamos. Hay más en este ejemplo de componente. Solo quería ilustrarte un poco una situación un poco complicada. Así que, imagina que tienes este componente. Este es el mismo componente que usamos antes, el que tiene la clave de estado. Imaginemos que uno de tus compañeros de trabajo abre un PR, tratando de agregar más datos en este componente.

Digamos que simplemente agregan una propiedad name, y cambian un poco la salida de JSX. Esto no es gran cosa, y aceptaríamos este PR, muy probablemente, aunque simplemente no hablaremos sobre por qué la propiedad name y entity son propiedades separadas, pero dejémoslo como está, y aceptemos este PR. Pero, si usáramos React Compiler, querríamos darle una segunda consideración a este PR, básicamente, porque así es como nuestro componente se veía antes del PR.