If You Were a React Compiler

[♪ música ♪ He sido desarrollador durante unos 25 años. Soy el director de educación para el grupo SMYTH, S-M-Y-T-H, y he enseñado a unos 350,000 estudiantes los fundamentos web en mis cursos en Udemy, Pluralsight y otros lugares, y actualmente puedes encontrarme en understandingreact.com para profundizar en el código fuente de React.

Y la charla de hoy se titula, Si Fueras un Compilador de React. ¿Cuál es la herramienta más poderosa en el cinturón de herramientas de un desarrollador? Bueno, muchas personas podrían tener diferentes respuestas a eso, pero creo que la herramienta más poderosa en el cinturón de herramientas de un desarrollador es un modelo mental preciso, lo que significa que tienes una comprensión razonable de cómo funcionan las herramientas que usas. Porque si tienes una comprensión razonable de cómo funcionan las herramientas que usas, tomas buenas decisiones arquitectónicas. Tienes confianza al usar la herramienta. Y eres capaz de depurar cuando las cosas no van como se espera.

Así que en esta charla, el objetivo es construir un modelo mental preciso de cómo funciona el nuevo compilador de React. Y para hacer eso, vamos a pretender que somos el compilador de React. Vamos a tomar un ejemplo de código que es lento, e intentaremos hacer lo que hace el compilador. Así que si vamos a ser el compilador, tenemos que tener algunas reglas básicas. ¿Cuál es nuestro enfoque y cuáles son nuestros objetivos? Bueno, sabemos que React por diseño llama a las funciones que le damos, es decir, nuestros componentes, una y otra vez. Ahora, a React le gusta llamar a eso re-renderizado de componentes. Pero realmente, le damos a React nuestros objetos de función, y luego React elige cuándo ejecutar y re-ejecutar esas funciones. Y eso significa que el rendimiento de React puede estar ligado a la frecuencia con la que se llaman nuestras funciones, y cuánto trabajo hacen nuestras funciones.

Entonces, ¿cuáles son nuestros objetivos? Bueno, nuestros objetivos como compilador son minimizar los re-renderizados, es decir, minimizar con qué frecuencia, cuántas veces, se llaman nuestras funciones que le damos a React una y otra vez, y omitir cálculos costosos si no necesitamos ejecutarlos. Y eso mejorará nuestro rendimiento. Ahora, ha habido cierta controversia en línea sobre si el compilador de React es un compilador, así que saquemos eso del camino. En los currículos de ciencias de la computación, a menudo se introduce a las personas a los compiladores cuando se habla de convertir lenguajes de programación de alto nivel en lenguaje de máquina, y eso es cierto. Pero también siempre ha sido cierto que existe algo llamado un compilador de fuente a fuente. A veces lo llamamos un transpiler. Y eso es esencialmente lo que es el compilador de React. De fuente a fuente, toma el código como entrada y genera un código equivalente, código que hace lo mismo que nuestro código original, pero con algunos extras. Y eso es lo que hace el compilador de React. Así que si somos el compilador, vamos a hacer lo mismo que hace el compilador de React.

Ahora, cuando un programa que funciona como compilador se ejecuta, analiza el texto del código. Así que eso es lo que haríamos. Ahora, en el caso de un compilador real, podría convertir el texto en algo llamado un árbol de sintaxis abstracta. Así que podría tomar una línea de código que escribimos y luego convertirla en algún tipo de estructura de objeto, que luego puede ser recorrida, razonada, etcétera, y luego generar nuevo texto, nuevo código. De fuente a fuente.

Y luego va a tomar esa idea y proceder algorítmicamente. Va a recorrer nuestro código y tomar decisiones sobre qué código va a generar. Así que eso es lo que vamos a hacer. Simplemente vamos a proceder algorítmicamente. Y veremos qué sucede.

¿Cuál es la primera cosa que necesitamos hacer? Bueno, nuestro objetivo es evitar useMemo, memo, useCallback. Así que necesitamos prepararnos para memoizar valores. Así que comencemos observando algo de código. Este es un ejemplo muy artificial, pero es una charla de 20 minutos. Así que los ejemplos artificiales pueden ser útiles. Así que aquí está nuestro ejemplo artificial. Y tengo algo de código ajustado a la derecha, pero puedes prestar atención al código a la izquierda, y lo moveremos de un lado a otro un poco.

Así que tengo un contador muy, muy simple. Ejemplo clásico, pasándole un count y una función de incremento. Tengo una función intencionalmente súper lenta. Ahí está nuestro problema principal. Y luego he levantado el estado al nivel de la app aquí, y esencialmente tengo algunos re-renderizados innecesarios ocurriendo. Lo que estoy haciendo es que tengo un par de clics para sumar dos números, y eso va a ser lento. Y luego estoy llamando a mi componente de contador, que solo va a incrementar su propio estado. Así que termina luciendo así. Hago clic fue 5 más 10. Es lento. Ahora es 5 más 11. Y eso está bien, pero nota que el contador también se renderizó. No necesitaba hacerlo. Y luego, cuando hago clic en más en count, nuevamente ejecuta esa función lenta y luego incrementa. Así que eso es un problema.

Ahora, tenemos algunas maneras de manejar esto, y una de las maneras sería que manualmente hagamos use memos y use callbacks, etcétera. Pero no vamos a hacer eso. En su lugar, vamos a proceder algorítmicamente.

Voy a estar preparado para poder poner cosas en memoización. Así que {{^}}voy a dejar caer una función simple aquí, y {{^}}voy a definir el concepto de vacío. Simplemente voy a hacerlo un símbolo porque no quiero preocuparme de si es null o undefined. ¿Es ese un valor preciso? Quiero saber que esto está vacío, voy a tener lo que es esencialmente un hook personalizado, C para cache, digamos, y va a memoizar un array del tamaño que le dé y llenar ese array inicialmente con esa representación de un valor vacío. Y eso es todo.

Ahora, cuando vaya a usarlo, y solo tendré mi código de referencia aquí. Vamos a pasar por un poco. Cuando empiece a trabajar algorítmicamente a través de todo este código, lo primero que siempre voy a hacer es decir, bueno, sé que quiero este array de posibles valores memoizados para este componente. Este componente ahora va a ser optimizado. Pero no voy a pasar por y añadir use memos literalmente en todas partes. Simplemente voy a tener un array de valores en la parte superior. ¿Y qué está pasando realmente aquí cuando hago eso? Bien, refresquemos esto y asegurémonos de que tenemos... Asegurémonos de que tenemos eso en su lugar. Y me perdí mis use memos, así que hagámoslo. Y simplemente dejaremos que esto se refresque.

Bien, eso está corriendo, pero ¿dónde están los valores memoizados? ¿Dónde está ese array vacío? Bueno, es interesante. En realidad podemos ir a buscar el elemento de sección creado en ese contador. Y en el elemento de sección, en realidad puedo obtener una referencia, ves eso allí, al nodo en el fiber tree que es lo que coloquialmente ahora llamamos el DOM virtual. Puedo ir a buscar o encontrar ese nodo que generó ese elemento DOM, así que vamos a obtener eso. Y dentro de eso, puedo ir a encontrar su padre, que se llama return. ¿Cuál es el padre de esta sección? Es Counter. Y ahí está. Y en ese nodo del DOM virtual del fiber tree, es decir, hay un array, y ahí están todos mis valores vacíos en el array. Así que el valor memoizado simplemente está sentado en un objeto de JavaScript en la memoria en el navegador. Y mientras React está recordando y llamando una y otra vez mis funciones, puede acceder a esa parte del nodo colgando del fiber tree. Se ve un poco como... vamos a mostrar esto. Se ve un poco como esto. Siempre que usas un hook, en realidad se está moviendo hacia abajo el siguiente valor en una lista enlazada. Así que cada vez que ves Use algo, en realidad significa moverse al siguiente valor en la lista enlazada, y ahí están los datos que necesito para ese valor, ya sea estado, callback, memo, lo que sea.

Pero ahí está, sentado en la memoria. Así que estoy preparado para poner cosas en memoria. Y lo que quiero poner en memoria son funciones, o realmente los valores de retorno de las funciones. Y mi suposición es que las funciones son puras. Esa es una de las reglas de React, ¿verdad? Que si le doy a una función la misma entrada, siempre obtengo la misma salida, y eso me permite memoizar o almacenar o guardar el valor de esa función cuando le doy la misma entrada para no ejecutar la función nuevamente.

Bien, aquí hay una pregunta, compiladores. En esta simple función de contador, ignorando la consola, ignorando estas dos líneas aquí arriba, ¿hay otras funciones siendo llamadas en este ejemplo simple? La respuesta es sí. Porque recuerda, nuestro modelo mental de React, escribimos JSX, pero ¿qué es JSX? JSX son llamadas a funciones. No está realmente llamando a nuestras funciones, está llamando a funciones internas de React y le estamos dando objetos de función para llamar o le estamos dando cadenas que dicen, llama a estas funciones internas que React ya tiene, y construye el DOM. Si soy el compilador y estoy diciendo que no quiero volver a llamar a una función si no es necesario, entonces también quiero memoizar las funciones a las que se convierte el JSX. Y la dependencia serían las cosas que se pasan a esas funciones, que tendemos a llamar children. Esos son realmente solo un objeto o un array que se pasa en esa llamada a función.

Si empiezo a pensar en esto de manera programática, ¿qué voy a hacer? Bueno, me voy a encontrar, digamos que tomamos este párrafo. Voy a decir, bueno, tengo un valor. Nuevamente, solo voy a pensar algorítmicamente. No voy a pensar demasiado profundamente. Y voy a verificar si ese primer valor es igual a count. Si mi función de contador se llama nuevamente y se le pasa count, voy a verificar si ya he almacenado ese mismo número en el array de memoización. Y si no lo he hecho, entonces necesito esencialmente llamar a mi función nuevamente, porque hay un nuevo valor de count. Si originalmente era count cero y estoy más allá de cero, ya conozco el resultado, p count colon cero. Pero si es uno, ahora necesito recalcular eso. Y lo que puedo hacer entonces es almacenar ese valor para comparar con el nuevo valor. ¿Y sabes qué? Voy a almacenar realmente los resultados de esa llamada a función, porque si almaceno los resultados de la llamada a función y se introduce el mismo valor de count, no tengo que hacer nada de eso. Puedo simplemente decir, ve a buscarlo de la memoización. Y luego puedo realmente reemplazar este p con ese b cero. ¿Tiene sentido? Bastante simple, ¿verdad? Si hiciera esto algorítmicamente una y otra y otra y otra y otra y otra y otra y otra y otra y otra y otra, ¿qué obtengo? Bueno, obtengo una secuencia de declaraciones if colocando valores en ese array memoizado donde siempre estoy verificando las dependencias. En este caso, button tiene una dependencia de increment, que es una función que se pasa. Puedo ir a app, todavía tengo mi use state. Almaceno un nuevo array memoizado, que se almacena ¿dónde? En el nodo app, en el fiber tree que está asociado con esa llamada a función. Y los reviso.

Aquí está mi función lenta. Ahora tiene dos dependencias, así que solo voy a verificar, ponerlas en el array de memoización, ver si han cambiado. Oh, esta era solo la función increment, que no tiene parámetros. No, solo necesito crearla una vez. Así que esta es mi pequeña excepción. Voy a decir, bueno, si está vacío, ese lugar en el array de memoización, entonces crea la función, de lo contrario, simplemente sáquela. Porque mientras lo haga una vez, una vez que ya no esté vacío, sé que tengo la función correcta. Bien. Y llamaré a eso increment. Y haremos lo mismo. Todas estas pequeñas piezas de JSX. Esta tiene num1, num2, y sum, así que verificamos todos esos.

Y verificamos, y verificamos, y verificamos, y verificamos, y verificamos, y verificamos, y verificamos, y lo sacamos, y lo guardamos. Y actualizamos. Vamos a actualizar. Todavía va a ser lento en la carga inicial. Todavía estamos llamando a eso. Pero mira lo que pasa cuando hago clic en count. ¡Yay! ¡Súper rápido! Y nada más se está renderizando. Y cuando hago clic en el lento, sigue siendo lento. Pero el contador no se vuelve a renderizar. Entonces, ¿qué acaba de pasar? Acabo de memorizar todo. Pero no lo hice demasiado profundamente, ¿verdad? Solo lo hice algorítmicamente. Y el resultado es un código que podemos entender.

De hecho, lo puse en el playground del compilador de React, y aquí está el código que salió. ¿Te resulta familiar? Hmm. ¿Podrías escribir un código como este? Tal vez no quieras. Probablemente podrías si realmente tuvieras que hacerlo, ¿verdad? Pero eso es lo grandioso de una herramienta. Es una herramienta que pasa y hace ese trabajo por nosotros, para que podamos centrarnos en crear grandes aplicaciones, en crear un gran software. Pero la idea es que no tenemos que pensar en ello.

¿Por qué no tenemos que pensar en ello? Bueno, porque tenemos una herramienta que lo hace por nosotros. Y no necesitas entender las complejidades de cómo funciona un compilador para usar el compilador de React. Pero la herramienta más poderosa que un desarrollador puede tener en su cinturón de herramientas es un modelo mental preciso. Siempre te beneficiarás de saber cómo funcionan las cosas. Y así, cuando miramos el compilador, no es una caja negra mágica que hace que tu aplicación sea más rápida. El compilador es una herramienta que analiza el texto de tu código, añadiendo memorización, añadiendo verificaciones de dependencias en llamadas a funciones, incluyendo el JSX, en lo que se transpila, y eso es todo.

Es un código que podrías escribir si tuvieras la inclinación y el tiempo. Si fueras un compilador de React. Y eso es todo. Soy Tony Alisea. Puedes encontrarme en understandingreact.com para profundizar completamente en el código fuente de React para ti y tu equipo. Ahora es un buen momento para unirte a mí allí.

Y espero que disfruten de la última charla de la conferencia. Gracias a todos por el placer.

Aquí hay una pregunta rápida, súper fuera de lugar. Tu primera computadora. TRS-80 Color Computer 2 Tandy. Bien. Nadie aquí sabe qué es eso. Sí, bien. Muy bien, muy bien. Muy bien. Ahí vamos. Y la otra cosa que quiero decir, Ron Harper. Oh, eso es todo. Sí, ahí lo tienes. Solo estamos teniendo una conversación. Tuvimos toda una conversación sobre los deportes de Cleveland. No entremos en eso. Muy bien, no mucho tiempo.

Entremos en el primero que les va a gustar, que estaba en tu código, solo se memorizó el valor más visto. ¿Hace, oh, se acaba de mover. ¿Hace, se acaba de mover de nuevo. Espera. ¿Dónde estás? ¿Funciona un compilador de React de la misma manera? ¿Solo un valor? Tratando de entender. En tu código, solo se memorizó el valor más visto. ¿Funciona el compilador de React de la misma manera? Solo un valor. No estoy seguro de entender completamente la pregunta. Lo que diré es que el compilador está pasando y memorizando los resultados de las llamadas a funciones, ¿verdad? Y siempre va a depender de cuántos parámetros, argumentos se pasen a esa función, siempre que la función sea pura. Bien. Y de nuevo, solo voy a decirlo, ya sabes, si leemos la pregunta, no está lo suficientemente clara, lo que sea, habrá una especie de oportunidades para tener una más directa. Sí, lo siento por eso.

Si quieren aclarar. Oh, sí, exactamente. Y quiero disculparme. No lo estoy leyendo correctamente. Roger, gracias por el reconocimiento. Pero solo quiere decir que esta charla fue increíble. Así que merci, Roger. No es que deba tomar el crédito. Esto es para lo que vinimos.

¿Hay preocupaciones de memoria al memorizar todo? Esa es una gran pregunta. Potencialmente, ¿verdad? Creo que para la mayoría de las aplicaciones comunes de React, no será un problema. Pero es algo de lo que hay que estar consciente. Así que si vas a usar el compilador, que es una gran herramienta. Claramente va a ahorrar mucho trabajo. Si estás volcando una gran cantidad de información en los resultados de tus llamadas a funciones, entonces debes ser consciente de que eso va a estar ahí, si estás haciendo actualizaciones del lado del cliente con React, eso va a estar en el cliente del usuario en su navegador. Y eso es algo que al menos hay que mirar, ¿verdad?, en las herramientas del navegador para estar consciente. Gracias por esa pregunta nuevamente.

¿Dónde fuiste? Ahí estás. ¿Cómo detecta el compilador de React cuando los valores de cierre de una función habrían necesitado cambiar, incluso si su lista de parámetros está vacía? Sabes, esa es una buena pregunta. Sé que el equipo del compilador, lo que mostramos hoy no es todo lo que hace el compilador. No es el alcance de sus habilidades. Así que está analizando estáticamente tu código y está utilizando una variedad de técnicas para hacerlo. Así que diría que el compilador claramente ha sido probado intensamente y ya se usa en producción. Así que creo que se trata más del código del compilador haciendo análisis estático y tomando esas determinaciones generando árboles de sintaxis abstracta, generando todo lo que necesita generar para hacer esas determinaciones. Si alguien está preocupado por si algo funciona o no, digo que lo mejor es probarlo. Incluso solo colócalo en el playground y ve cuál es la salida y luego sigue desde allí. Genial. Me gusta esta pregunta de anónimo.

¿Por qué React se alejaría de esto y hay alguna preocupación de memoria mientras lo hacemos un poco… Sí. Bueno, por un lado con el compilador, no puedes optar por no participar. Así que puedes poner una nota en una función particular para decir, por favor no optimices esta función. Así que eso es una preocupación. Hay habilidades de exclusión. Y creo que por otro lado, el tamaño de los resultados para la mayoría de las cosas, como un fragmento de JSX o algo así, es bastante insignificante. Así que creo que lo original dentro de los documentos de React sobre preocuparse solo por cosas grandes es porque React no está tratando de alentarnos a usar memo en todas partes manualmente. Así que estás diciendo, bueno, no te preocupes por memorizar todo. Eso es trabajo innecesario. Pero en el caso del compilador, realmente no importa porque no estamos haciendo ese trabajo manual. Muy bien.

¿Cuál es la parte más interesante de los internos de React? Oh, creo que el Fibre Tree es fascinante. Cómo funcionan los hooks y realmente cómo el proceso de reconciliación surge de eso. Pero solo el Fibre Tree en general es interesante. Lo que solíamos llamar el DOM virtual. Gran parte de lo que React es y hace ahora está centrado en ese árbol. Programar trabajo, pausar trabajo, ayudar a que las cosas sean optimizadas y rápidas. Así que creo que profundizar en cómo funciona el Fibre Tree es algo excelente para un desarrollador de React. No es 100% requerido, pero es realmente fascinante y útil. Genial.

¿Cómo interactúa el compilador con los arrays de dependencias de efecto? Ooh, esa es una buena pregunta. No creo que sepa la respuesta a eso. Asumiría que probablemente lo ignora. Como el array de dependencias de use effect, porque ya está ahí. Ya está como que solo va a ejecutarse cuando las dependencias cambien. Pero no estoy 100% seguro. Bien. Y nuevamente, si entre ahora y cuando vayamos a la sesión de preguntas y respuestas, si quieres hacer esa pregunta de nuevo, o quieres aclarar, por favor, las oportunidades estarán ahí. ¿Dónde está esa pregunta? ¿Sabes cómo todo este código de memorización afecta el tamaño del bundle? Esa es una pregunta interesante. Obviamente, estamos agregando algunos if statements.

Pero si realmente miras el código generado, en lo que JSX se transpila es probablemente más grande y más complicado que lo que el compilador está generando. Así que no creo que tenga un impacto tan grande como alguien podría pensar.

Genial. Gracias. ¿Entiendo que un compilador estoy almacenando en caché los valores de las funciones que los hijos podrían llamar y comparando nuevos valores con los antiguos para luego actualizar la caché? OK, no estoy seguro si eso es una pregunta real. Tal vez no estoy leyendo bien. Sí, creo que entiendo lo que están diciendo. Sí, lo eres. Cada vez que se llama a tu función, se vuelve a renderizar, se vuelve a ejecutar, se está comparando con lo que ya está en la caché.

Si coincide, no se molestará en ejecutar la función. Si no coincide, ejecutará la función. Muy bien, gracias. En tu código, solo se memorizó el valor más visto. ¿El compilador de React funciona de la misma manera, solo un valor? Esa es la pregunta principal. En el código, solo se memorizó el valor más visto. Sí, creo que esa es la pregunta que hicimos antes. ¿Lo hice? Siento que podría tener que dejar eso. OK. Muy bien.

Está bien.

Voy a intentar resolver eso después. Lo siento. Genial. Lo siento. OK, acabo de ser desconectado. ¿Qué está pasando aquí? Disculpas, dame un segundo. No te preocupes. Oh, pero está aquí arriba. Oh, lo siento.

Entonces, ¿funciona con parámetros de objeto y arrays? Sí, en realidad, porque los objetos son— puedes argumentar sobre la igualdad de referencia en JavaScript, pero hay un grado de igualdad de referencia en JavaScript. Así que un array es un tipo especial de objeto. Así que vas a poder comparar esos dos.

Muy bien. Siguen llegando más preguntas. Increíble. En memoria, si la memoria es una preocupación, ¿podrías almacenar un hash del argumento de la función en la caché en su lugar? Esa es una pregunta interesante. Siento que eso es una posible optimización, seguro. Simplemente no estoy seguro de que sea necesario. Creo que si estás memorizando lo que llega como argumentos, probablemente no van a ser valores masivos. Supongo que eso es otra cosa en la que pensar. No solo si tu función está devolviendo arrays o objetos extremadamente grandes, sino también si estás pasando objetos extremadamente grandes a la función. Eso también es algo a tener en cuenta en términos de memoria. Pero de nuevo, creo que eso es— si estás pasando objetos increíblemente grandes a una función, eso puede ser una señal de que algo más está mal con la arquitectura.

Absolutamente. Y creo que esta será nuestra última pregunta. ¿Tienes alguna aprensión sobre el compilador? Habilita muchas características nuevas, pero ¿hay algún riesgo de romper el código que no usa el compilador? No lo creo. Puedes mirar el código que se genera.

Puedes entender el código que se genera, y luego tomar una determinación. Piénsalo como si otro desarrollador intentara optimizar tu código y ver qué aspecto tiene. Si vas a tener mucho código que se está ejecutando y siendo optimizado, claro, podrías tener una preocupación como, ¿qué va a pasar? Pero de nuevo, también podrías tomarlo pieza por pieza. Podrías decir, sé que esta interfaz de usuario en particular tiene algunos problemas. Voy a excluir todo lo demás, y solo voy a usar el compilador allí, ver qué pasa, y seguir desde allí.

Genial. Sr. Alisaiah, muchas gracias por su tiempo y su presentación. Gracias. Un aplauso para Tony, por favor. Lo aprecio.