Deep Dive on React Hooks Architecture

♪ Hola a todos, y bienvenidos a Deep Dive sobre React Hooks y Arquitectura. Mi nombre es Daniel Espino Garcia, un ingeniero de diseño de software en Mattermos. Entonces, ¿qué es Mattermos? Mattermos es una herramienta de colaboración de código abierto enfocada en escenarios críticos para la misión, pero eso no es lo importante para esta charla. Lo importante para esta charla es que tanto la aplicación móvil como la web están escritas en React, y utilizan principalmente componentes funcionales. Así que, sí, eso es lo que usamos.

¿Y por qué estoy hablando de esto? Bueno, soy ingeniero. Me gusta desarmar cosas y ver cómo son por dentro. Y con la magia del código abierto, puedo hacer eso con React. Puedo ir directamente al código fuente y ver toda esa magia alrededor de los hooks, sobre cómo las funciones pueden almacenar un estado y cosas así. ¿Cómo funciona todo eso? Así que tenía curiosidad al respecto. Lo investigué e hice una charla sobre eso.

Así que antes de comenzar, todas las imágenes de rebel bug durante la charla son generadas por IA. Por eso no son lo más consistente. No tengo ninguna relación con el equipo de React. Solo soy un tipo que está mirando el código y sacando conclusiones. Así que no sé las razones exactas por las que las cosas se hicieron de una manera u otra, y puede que esté entendiendo mal las cosas del código. Así que todo lo que he mostrado aquí se basa en lo que encontré en este repositorio, en el repositorio de React. Y finalmente, en algún momento, me quedé atascado y tuve que buscar ayuda afuera, y encontré este post en un blog que fue realmente interesante para entender cómo funciona todo el asunto de fiber. Y eso me permitió volver a encarrilarme. Pero, bueno, sin más preámbulos, ¿qué vamos a ver? Bueno, vamos a ver, nuestro tren va a ir desde el componente. Escribimos nuestro componente de función hasta el render, cómo llega a la pantalla. Pero para hacer eso, tenemos que tomar un camino más largo. Primero que nada, tenemos que entender qué es JSX. Entendemos qué es JSX, tendremos que entender qué es un elemento de React, luego qué es un fiber. Luego tendremos una mejor comprensión de qué es nuestro componente, lo que nos llevará a entender los hooks, lo que nos llevará de vuelta a los fibers y cómo todo eso se renderiza. Así que comencemos con eso. ¿Qué es JSX? JSX es simplemente escribir HTML dentro de JavaScript. ¿Y qué es todo eso? Es solo azúcar sintáctica. El transpiler maneja todo esto. Y con una herramienta como esta, puedes obtener el resultado.

Y el resultado es mucho de React.createElement. Así que como puedes ver, tu función, lo que hace es hacer un React.createElement y devolver eso. Eso es todo lo que hace. Así que, cosa interesante. Debes importar React. Porque si el transpiler sustituye cosas a React.createElement, necesita que React esté en el contexto. Es por eso que a menudo obtienes estos errores como, oye, estás en un archivo JSX y no has importado React. Tienes que importar React. Esta es la razón. De hecho, hay un nuevo runtime que, en teoría, se deshace de eso. Pero, sí, no he profundizado en eso.

Así que tenemos este React.createElement. Eso es lo que nuestro componente de función está devolviendo. Pero, ¿qué es realmente un React.createElement? Así que si vamos a esta parte del código, vemos que React.createElement es solo un objeto. El componente en sí ni siquiera es llamado. El componente se va a almacenar en type. Así que type almacenará una función, nuestro componente de función. Así que, bien, si nuestro componente aún no se ha llamado, ¿cuándo se llama mi componente de función? Bueno, bien, así que tenemos componentes que solo devuelven un React.createElement. Y si subimos por ese árbol, llegaremos a la raíz.

Y la raíz, según una plantilla, debería ser algo como esto, React.createRoot, y luego root.render. Así que centrémonos en la primera parte, en createRoot. ¿Qué hace eso? Crea un host root. Un host root fiber. Entonces, ¿qué es un fiber? Un fiber es trabajo en un componente que necesita hacerse o se hizo. Esa es la definición que tienen en el código, en algunos comentarios. Así que, bien, es trabajo en un componente que necesita hacerse o se hizo. ¿Y qué significa la parte de host root? Es una referencia a una raíz en el sistema host. El sistema host, en nuestro caso, será el DOM. Bien. Estamos creando esta raíz que tiene una referencia a algún lugar en el DOM, y luego estamos llamando a render.

Bien, ¿y qué estábamos pasando a render? JSON, así que ReactElement. Esto aún no está llamando a mi componente de función. ¿Cuándo se llama a mi componente de función? Entonces, lo que hace render es programar el root fiber. Así que llama a render, que llama a updateContainer, que llama a scheduleUpdateOnFiber, que llama a ensureRootIsScheduled. Eso, al final del día, lo que está haciendo es agregar la raíz a una lista enlazada. Agrega la raíz allí a estas variables globales, que es la primera raíz programada y la última raíz programada, para que esta lista enlazada funcione.

Y luego entra en juego el scheduler. El scheduler es otra bestia. Podrías hacer toda una masterclass solo sobre el scheduler de React. Así que lo mantendré simple, y solo diré que un scheduler, siempre que ve que tiene que hacer algo en una raíz, realiza trabajo en esa raíz, ese trabajo se divide en unidades de trabajo para que React pueda detener el renderizado en cualquier momento, para que otros procesos no sufran inanición. Así que puede hacer cosas por unidades de trabajo, y luego comenzar a trabajar en un solo fiber. Así que para decidir qué hacer con ese fiber, se basa en ciertas etiquetas que tiene el fiber.

Así que cuando comenzamos el host root fiber, lo que hace es ver que es un host root, así que llama a mount children. Mount children buscará en los contenidos, buscará en este React element, y creará un nuevo fiber. Este fiber es un function component fiber para nuestro componente de aplicación, digamos. Luego el scheduler dirá, oye, este fiber tiene ese function component, así que tengo que llamar a renderWithHooks. RenderWithHooks es el responsable de ejecutar realmente nuestro componente de función. Y si recuerdas lo que hace el componente de función, devuelve un React element. Así que eso se pasa a mount children, y ahora puede montar un hijo para ese componente.

Esto creará todo el árbol, y si estos hijos tienen hermanos, los hermanos también estarán vinculados al menos horizontalmente. Así es como React crea este árbol de fiber. Entonces, cuando tenemos el árbol de fiber, React también necesita saber qué cambió desde el último renderizado. Así que React siempre almacena dos árboles diferentes. El árbol actual que representa lo que está ahora en la pantalla, y el que está en progreso. Así que cuando el scheduler se ejecuta de nuevo, comenzará a crear el árbol en progreso. Diremos, está bien, tiene una raíz host, es la misma, tengo la app, es la misma, tengo el hijo, es el mismo que antes.

Oh, pero este hijo ya no tiene hermanos, así que marcaré estos hermanos para ser eliminados. Y luego tiene un hijo, es el mismo, oh, pero esta imagen tampoco está allí, así que marcaré esto para ser eliminado. Y cuando termine, simplemente sustituirá el actual con el que está en progreso, para que en la próxima iteración pueda hacer todo esto de nuevo. Bien, eso es todo por ahora con el árbol de fiber. Entonces, ¿dónde están mis hooks? Ahora sé que nuestro componente se ejecuta cuando es renderizado por el árbol de fiber, pero ¿qué, por ejemplo, cuando tengo un useState, dónde está viviendo ese estado? Bueno, vamos a ver eso.

Primero que nada, voy a usar el hook useCallback porque siento que es lo suficientemente complejo y lo suficientemente simple para darte un enfoque inicial interesante de lo que hacen los hooks. Así que si miramos el código en el archivo react-hooks, vemos que useCallback, lo que hace es obtener un dispatcher y llamar a la versión useCallback de ese dispatcher. Bien, eso no hace nada. Entonces, ¿qué es ese dispatcher? Bueno, el dispatcher viene de una variable global compartida entre diferentes archivos. Eso es el react-share-internals. Bien. ¿Cómo se asigna eso? Bueno, cuando estás renderizando el hook, dice, oye, cuando estás tratando con un fiber, dice, oye, hay un fiber actual.

No, entonces es montaje. Si hay un fiber actual, significa que ya hemos renderizado ese fiber. Así que lo que necesitamos hacer es actualizar. Así que si recuerdas los dos árboles diferentes, la idea es que algunos elementos pueden no tener un fiber previo para consultar. Así que esos se montarán, y aquellos que tienen un fiber previo allí en el árbol actual simplemente se actualizarán. Bien.

¿Cómo se ven estos dos dispatchers? Bueno, simplemente llaman a una función de montaje diferente o a una función de actualización. La mayoría de ellos. Hay algunas excepciones, pero las que vamos a examinar simplemente deciden entre montaje o actualización. Entonces, montaje de callback. ¿Cómo se ve? Bueno, tenemos un hook que monta el hook en progreso. Bien. Y luego simplemente almacenamos en el estado de memoria el callback y las siguientes dependencias. Perfecto. ¿Qué es ese hook? ¿De dónde viene? Bueno, ese hook es solo un objeto. Nuevamente, realmente simple.

Memo es un estado, algunas otras cosas que se necesitan, y una propiedad siguiente para hacer otra lista enlazada. Así que lo que estamos haciendo es crear este objeto y agregar ese objeto al estado memorizado del fiber que se está renderizando actualmente y simplemente crear allí una lista enlazada. Bien. Como puedes ver allí en React, estamos usando muchas variables globales. En este caso, el fiber que se está renderizando actualmente, el hook actual, el hook en progreso. Esto se usa para orquestar todo lo que sucede al mismo tiempo. Bueno, incluso si probablemente te han dicho que las variables globales son malas, aquí cumplen un propósito y se usan correctamente.

Entonces, sí. Están usando estas variables globales principalmente para mejorar el rendimiento, ya que esta es una parte realmente difícil del código. Es genial que lo hagan de esta manera, aunque puede ser complicado para algunas cosas. Pero, bueno, volvamos al tema y veamos la actualización.

Al actualizar el callback, lo que estamos haciendo es obtener, nuevamente, el hook, verificando las dependencias si son iguales. Si son iguales, devuelve lo que teníamos en el estado memorizado. Si no, actualiza el estado memorizado con el callback y las siguientes dependencias. Y eso es todo. Bien.

Pero, ¿qué es este hook de actualización en progreso? Bueno, lo que hace es crear un nuevo objeto hook, obtener todo el estado del que está en el fiber actual, y luego agregarlo a la lista enlazada del fiber que se está renderizando actualmente. Así que, sí, es un poco confuso, pero veamos un ejemplo gráfico. Entonces, aquí tenemos un fragmento de código en la parte inferior que decimos, bien, voy a llamar a use callback y luego a use memo. Este es el estado inicial. Tenemos un fiber en progreso. Eso es lo que somos, el componente que estamos renderizando. Y no tenemos un fiber actual. El fiber actual apunta a null. Así que, por eso el dispatcher apunta a montar. Entonces, ¿qué pasa ahora? Llamamos a use callback. Crea un nuevo objeto hook, lo agrega a la lista enlazada, y luego agrega al estado memorizado la función y las dependencias. Luego llamamos a use memo. Entonces, crea un nuevo objeto hook, lo agrega a la lista enlazada, y agrega al estado memorizado el valor y las dependencias. Y eso es todo. Eso es lo que sucede al montar. Entonces, veamos qué sucede al actualizar. Ahora, el estado es el siguiente. Tenemos el fiber actual, las cosas que renderizamos en la ejecución anterior, y tenemos el fiber en progreso. Ese es el componente que estamos ejecutando ahora mismo. Así que el dispatcher va a actualizar porque tenemos nuestro fiber actual. ¿Qué hacemos? Bueno, llamamos a use callback.

Entonces, creamos un nuevo objeto, lo añadimos a la lista enlazada, y luego apuntamos a lo que teníamos en el anterior. Imaginemos que no hay cambios en absoluto. Así que no tenemos que actualizar el estado memorizado. Así que, para use memo, lo mismo. Entonces, se añade a la lista enlazada, y obtiene el valor anterior. Nuevamente, no lo estamos actualizando porque nada ha cambiado. Y, sí, eso es lo que está sucediendo internamente.

Así que, ahora que has visto todo esto, puedes entender la regla de hooks. Si tienes, por ejemplo, este caso donde tienes el hook tres que se renderiza condicionalmente. Entonces, en el primer renderizado, tienes hook uno y hook dos ejecutándose. Tienen su estado memorizado creado, sus hooks creados, y así sucesivamente. Y luego, en el siguiente renderizado, tienes hook uno, hook dos y hook tres. Entonces, cuando llegas al hook tres, ¿dónde está mi estado memorizado? El hook tres no encuentra su estado memorizado y está tratando de actualizar. Así que, eso es un problema. La otra cosa que puede suceder es esta. Tienes la primera iteración que llamas uno y dos y la segunda iteración que llamas uno y tres. En ese caso, puedes encontrar un estado memorizado. Pero, oye, ese no es mi estado memorizado. Eso no es lo que estoy buscando.

Así que, sí, por eso tenemos la regla de hooks. Porque la forma en que está implementado, estos problemas podrían suceder. Así que, veamos otros hooks, lo que hacen. Entonces, useRef. useRef es el más simple. Solo almacena el objeto de valor actual en el estado memorizado y sigue devolviendo ese objeto. useEffect está en el estado memorizado. Almacena el efecto que incluye la función creadora y un objeto para almacenar la función destructora. Además, encola el efecto en el fiber.

¿Qué sucede entonces? Cuando encolas un effect en el fiber, este effect se llamará en un momento diferente. No se llamará justo después del render. Cuando el scheduler está realizando el trabajo en root, entrará en un finish concurrent render, commit root, y finalmente, ejecutará los efectos pendientes. Ahí es cuando se llamarán nuestros efectos. Así que, sí, se llamará después del render.

Entonces, ¿qué pasa con useState? useState también es bastante complejo porque, en primer lugar, en el montaje, almacenará el estado inicial, y luego creará una cola para los cambios de estado. Y luego creará la función dispatch para añadir cosas a esa cola. Y finalmente, devolverá el estado inicial y la función dispatch. Entonces, ¿qué hace esta función dispatch? Si está en render, lo actualiza en la cola del hook. Y luego, establece una bandera que hace que se renderice justo después de que el componente se haya renderizado.

Así que no tiene que ir al DOM ni nada. Lo hace automáticamente después de que el estado haya cambiado. Si no, si estás llamando a useState en otro lugar, lo añadirá a la cola, y luego marcará el fiber para re-renderizar. Así que el scheduler, la próxima vez que pase por el árbol, sabrá que ese fiber necesita re-renderizarse. Bien. Pero, ¿qué sucede entonces en la actualización? En la actualización es cuando se aplican todas las actualizaciones. Así que las actualizaciones no se aplican hasta que realmente renderizamos. Y todas las actualizaciones se aplican secuencialmente. De esa manera, luego almacenamos el nuevo estado calculado en el estado de memoria, y devolvemos el estado y la función dispatch. Así que eso es lo que hace useState. Y sí, eso es todo. Esa es la magia de los hooks. Así es como estas funciones pueden almacenar estado. Como puedes ver, la magia es un montón de variables globales, un montón de lista enlazada, y un montón de objetos viviendo en memoria. Entonces, ¿cuál es el costo real de usar hooks?

Por ejemplo, para useRef, es de orden constante. Para useCallback, depende del número de dependencias. Y useState depende del número de actualizaciones. Así que, si tienes algo que actualiza el estado mil veces entre renders, eso va a ser un impacto en la CPU, pero probablemente nadie está haciendo eso. Luego está la memoria. Tienes que almacenar el objeto del hook, tienes que almacenar las colas, los efectos, tienes que almacenar el estado memorizado, tienes que almacenar las dependencias. Esas pueden ser muchas cosas para almacenar las dependencias. Pero, bueno, veamos un ejemplo práctico. Por ejemplo, tenemos un useMemo, o simplemente pasando el estilo así. Entonces, la opción de la derecha, en teoría, es mejor, porque de esa manera no tenemos que verificar la altura en cada render. Así que, eso es menos CPU. Y no tenemos que almacenar la lista de dependencias con la altura, no tenemos que almacenar el objeto de altura, el objeto de estilo en el hook para devolverlo cada vez. Así que, el de la derecha es mejor, ¿verdad? Bueno, si miras más a fondo, los props todavía se almacenan en el fiber, porque los necesitas para comparar el fiber actual con el anterior para ver si algo ha cambiado. Además, la forma en que funciona el estilo es interesante por dentro. En el lado izquierdo, tienes lo que hace el DOM, y en el lado derecho, lo que hace React Native.

Ahora, al final del día, cuando estás pasando estilos, verificará cada estilo para ver si hay una diferencia para decidir qué estilo cambiar. Así que, sí, probablemente eso tomará algunos bucles más que simplemente usar un useMemo. Pero, bueno, eso es todo lo que quería compartir hoy. ¿Qué me perdí? Muchos detalles. También, reconciliación, componentes de clase, suspense, contexto, hidratación de renderizado en servidor, muchos hooks, reconciliación de hijos y manejo de claves. Me perdí muchas cosas, pero, bueno, son 20 minutos, y eso es lo que podemos incluir aquí. Pero, sí, todavía hay muchos detalles por explorar. Pero, bueno, podemos ver eso en el futuro.

Bien. Eso es todo por hoy. Muchas gracias. Que tengas un gran día.