Entendiendo la Arquitectura Fiber de React

Rate this content
Bookmark

Hemos escuchado mucho sobre la Arquitectura Fiber de React, pero parece que pocos de nosotros la entendemos en profundidad (o tenemos el tiempo para hacerlo). En esta charla, Tejas repasará su mejor intento de entender Fiber (revisado por otros expertos), y lo presentará de una manera 'explicar-como-si-tuviera-cinco años'.

Tejas Kumar
Tejas Kumar
29 min
21 Oct, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Esta charla explora la jerga interna de React, específicamente fiber, que es una unidad interna de trabajo para renderizar y comprometer. Las fibras facilitan actualizaciones eficientes a los elementos y juegan un papel crucial en el proceso de reconciliación. El bucle de trabajo, el trabajo completo y la fase de compromiso son pasos esenciales en el proceso de renderizado. Entender los internos de React puede ayudar a optimizar el código y las revisiones de las solicitudes de extracción. React 18 introduce las funciones de sincronización y asincronización del bucle de trabajo para características concurrentes y priorización. Fiber aporta beneficios como el renderizado asincrónico y la capacidad de descartar árboles de trabajo en progreso, mejorando la experiencia del usuario.

Available in English

1. Entendiendo el argot interno de React

Short description:

Bienvenidos de vuelta después del almuerzo. Esta charla es sobre el argot interno de React, específicamente fiber. Fiber es algo interno que React utiliza como una sola unidad de trabajo para renderizar y comprometer. No está expuesto a los usuarios, a diferencia de los elementos de React. Los elementos describen el estado deseado de la interfaz de usuario, mientras que los fibers son internos y efímeros. Trabajan juntos para construir grandes aplicaciones.

Bienvenidos de vuelta después del almuerzo. Espero que estén listos para algo profundo en esta conferencia tan avanzada. Permítanme comenzar diciendo que esta es una charla que nadie necesita escuchar. En serio, nadie necesita escuchar esto. Espero que algunos de ustedes quieran escuchar esto. ¿Quieren? Vale. Pero nadie, porque aquí está la cosa, esto es sobre el argot interno de React. Son cosas que podrían interesarte, como a mí, si eres curioso. No necesitas saber estas cosas para construir grandes aplicaciones con React.

React es la mejor manera de construir interfaces de usuario en la Web. Y no necesitas conocer los detalles internos para eso. ¿Quién quiere sumergirse en los detalles internos hoy solo por diversión? Sí, eso es. Vamos a hacer esto. Vamos a poner en marcha este espectáculo. Vamos a hablar de algo llamado fiber. Fiber es algo que no tengo mucho en mi... Pero, ¿qué es en el contexto de React? En pocas palabras, fiber... Y por cierto, vamos a sumergirnos en la arquitectura de fiber en 20 minutos. ¡Imagínate eso! Fiber en React es una sola unidad de trabajo. Hay una sola unidad de trabajo que React hace. Y podrías estar pensando, OK, ¿qué es el trabajo? El trabajo es esencialmente renderizar tus cosas y ponerlas en la pantalla. Renderizar y comprometer. Fiber es algo interno. De nuevo, así que no necesitas saber nada sobre ello para construir grandes aplicaciones con React. Y como tal no está expuesto a los usuarios. Así que quizás una forma más fácil de razonar sobre ello es pensar en algo que está expuesto y partir de ahí. ¿OK? ¿Qué está expuesto en React? El humilde elemento. Todos escribimos elementos de React. Escribimos un corchete angular con un nombre y eso llama a react.create element. Y tenemos elementos. Los elementos son con los que trabajamos diariamente. Y no voy a profundizar en los elementos porque ya lo hice una vez. Fue una charla relativamente popular sobre los elementos de React y cómo existen y cómo se crean y todo eso. Siéntete libre de ver eso en tu tiempo libre. Pero lo que quiero hacer es comparar y contrastar elementos y fibers para que tengamos, ya sabes, una idea de cómo trabajan juntos. Esencialmente lo que quiero resumir de esa charla para esta es que un elemento de React describe el estado deseado de la UI. Un elemento de React te permite describir, de manera declarativa, aquí está mi árbol de elementos de React. Esta es mi aplicación. Y luego React hace el trabajo de hacer eso la verdad en un entorno anfitrión. Así que en un navegador, en un dispositivo móvil con React Native, en una interfaz de línea de comandos con React, tus elementos describen lo que quieres. React hace que eso suceda. ¿Está claro? Genial. Entonces, ¿cómo entran los fibers en esta imagen? Para empezar, los elementos son públicos, es decir, son externos. Los escribimos. Pero los fibers son internos. No hablamos de ellos porque no necesitamos. Hay todo un equipo que trabaja con estos diariamente por nuestro bien, en nuestro nombre, para que podamos construir grandes aplicaciones. Los elementos son efímeros, así que no viven mucho tiempo. Puedes desechar los elementos. Puedes crear nuevos.

2. Entendiendo Elementos y Fibers

Short description:

Los elementos son efímeros, mientras que los fibers son estructuras de datos duraderas y con estado que React utiliza para rastrear el comportamiento y la apariencia de la aplicación. Los fibers facilitan actualizaciones eficientes a los elementos, evitando el re-renderizado innecesario. La reconciliación es el proceso de alinear la descripción de la interfaz de usuario con el entorno anfitrión, y los fibers juegan un papel crucial en esto.

Son solo una representación. Si hablas DevOps, son como un manifiesto de Kubernetes. Simplemente describes el estado que deseas, y luego un sistema lo lleva a cabo. O como un archivo de Terraform. ¿Algún DevOps en la sala? Oh, genial. Hola. Una persona.

Los elementos son efímeros. Los fibers son estructuras de data duraderas y con estado que React utiliza para seguir el rastro de lo que se supone que debe hacer tu aplicación. Lo que quieres que haga y cómo quieres que se vea. Y esa es la propuesta de valor de React en su totalidad.

Entonces, la forma de construir user interfaces que realiza actualizaciones eficientes y correctas a tus elementos de tal manera que no los descarte y te dé uno nuevo cada vez. ¿Puedes imaginar perder el estado de enfoque de tu entrada en cada pulsación de tecla? Desagradable. Entonces, los fibers facilitan eso. Y tercero, los elementos son inmutables. Es decir, no los cambias. Los desechas. Creas unos nuevos. Pero los fibers son estructuras de data duraderas, mutables y con estado utilizadas en el proceso de reconciliación. ¿Qué es la reconciliación? La reconciliación es cuando tomas un árbol de elementos, una descripción, un mapa de ruta de cómo quieres que se vea tu UI y cómo quieres que responda a los eventos y qué efectos quieres que tenga. Tomas esta lista de elementos y los reconcilias con un entorno anfitrión. El navegador o un dispositivo móvil o CLI. Eso es la reconciliación. Es esencialmente tomar tu descripción y hacerla la verdad. Los fibers son fundamentales en esto.

3. Entendiendo el Bucle de Fiber y el Proceso de Renderizado

Short description:

Ahora, entendemos cómo los elementos se convierten en fibers y la interacción entre ellos. El trabajo se realiza en el bucle de fiber, que establece flags y completa el trabajo en el árbol de fibers. El trabajo completo construye nodos DOM en un estado desconectado, y la fase de commit pone todo en la pantalla. La capacidad de pausar e interrumpir el renderizado es el punto principal de Fiber.

Ahora, entendemos los elementos, entendemos los fibers, entendemos la reconciliación. ¿Cómo se convierten los elementos en fibers? ¿Se convierten en fibers? ¿Cuál es la interacción? Hay una función en el código fuente code. Gracias a Dios que React es de código abierto y tiene licencia MIT. Puedo simplemente leer. Hay una función llamada create fiber from types and props. Podrías decir que esta función se llama create fiber from elements. Si has mirado un elemento de React, es un objeto JavaScript con propiedades de tipo, a veces propiedades de los hijos. Puedes decir que un fiber se deriva casi de los elementos y luego es utilizado por el reconciliador de fiber. Entendemos la reconciliación, entendemos los fibers. Todo se une en el reconciliador de fiber para hacer el trabajo de construir tus interfaces de usuario.

El trabajo se realiza en lo que se llama el bucle de fiber. Piénsalo como un bucle de juego. Cuando hay trabajo por hacer, inicias un bucle en la parte superior de tu árbol de fibers. Comienzas el trabajo. Estos son nombres de funciones en el código fuente code. Comienzas el trabajo en el nodo más alto. Y lo que hace begin work es esencialmente establecer flags. ¿Debería actualizarse esto? ¿Qué cambió? Establece un montón de flags. Y cuando termina, pasa al siguiente nodo en tu árbol. Y el trabajo comienza en eso. El siguiente siendo el hijo. Begin work establece algunas flags en eso. Si hay un hijo, simplemente sigue bajando, estableciendo flags hasta que no hay más hijos y entonces ¿qué sucede? Complete work. Ahora complete work hace algo más. También pasará al hermano como el siguiente. No el hijo. Si hay un hermano. Y luego vuelve a subir el árbol, completando el trabajo. Complete work construye nodos DOM, pero no en el DOM, en un estado desconectado. Así que no ves nada de esto en tu pantalla. Simplemente conecta nodos entre sí. Y finalmente tienes la fase de commit. Que es poner todo en la pantalla. Así que todo, hasta commit root, nada sucede en la pantalla. Y la razón de esto es, si el trabajo de renderizado necesita ser interrumpido o pausado, no es mientras el usuario está viendo que suceden cosas. Puedes desechar un árbol y recrearlo fuera de la pantalla y luego hacer el commit finalmente. Ese es el punto principal de Fiber, es la capacidad de pausar e interrumpir el renderizado y priorizar las actualizaciones. Algunas tienen alta prioridad, algunas tienen baja prioridad. Pero he estado hablando demasiado y honestamente no me gusta diseñar diapositivas. Así que simplemente dibujemos un diagrama y miremos algo de code. ¿Está bien? ¿Tengo permiso? Vale. Eso es agradable. Un woo. Vamos a conseguir esto. Así que tengo Excalidraw. Un aplauso. ¿A quién le gusta Excalidraw? Sí. Genial. Vizhou, gracias por esta herramienta. Así que vamos aquí.

4. Dibujando el Árbol de Elementos y la Reconciliación de Fiber

Short description:

Dibujamos un árbol de elementos, incluyendo un main, H1, div, span y botón. El reconciliador de fiber mantiene dos árboles: el árbol actual y el árbol de trabajo en progreso. Cuando se hace clic en el botón de más, el reconciliador de fiber actualiza el árbol de trabajo en progreso de forma desconectada y luego confirma los cambios. Comienza con el nodo principal, establece flags y se mueve a través del árbol, marcando actualizaciones y completando el trabajo.

Y lo que vamos a hacer es dibujar un árbol de elementos. Así que tenemos un main. Como hijo de main, digamos que tenemos un H1. En realidad, pongamos un div. Sopa de div. Mi desayuno favorito. H1. Y tenemos algunos hermanos para H1. Así que digamos que aquí tenemos un span y tenemos un botón. Vale. ¿Hay un reloj? Realmente no sé cómo voy con el tiempo. Pero eso está bien. No me muestres el reloj.

Entonces, bien, tenemos un H1. Y estos también tienen algo de texto debajo. Así que H1, digamos que esto es hola mundo así. El span, digamos que esto es una aplicación de contador donde estamos simplemente dibujando cosas. Y, por supuesto, digamos que esto es solo un contador unidireccional. Todo lo que puedes hacer es incrementar. Si pudiéramos hacer eso con mi salario, estaría realmente feliz. Genial. Así que este es un árbol de digamos elementos, digamos cinco, lo que sea, solo un árbol.

¿Cómo funciona el reconciliador de fiber? Ahora, en cualquier momento dado, el reconciliador de fiber mantiene dos árboles. Así que el paso uno, vamos a duplicar esto. Vamos a duplicar este árbol. Primero lo envolvemos en una bonita cajita, vamos aquí, y luego vamos a duplicar todo esto. Así que simplemente boom, segundo árbol, clon, vamos. Así que ahora tenemos dos árboles. El primero se llama el árbol actual, el segundo, vamos a llamarlo el árbol de trabajo en progreso. Y aquí es donde se hará mucho del trabajo de renderizado. Así que ahora la pregunta, ¿qué haría el reconciliador de fiber si yo hago clic en el botón de más e incremento el conteo? Eso es de lo que quiero hablar. ¿Y cómo lo hace? Así que hago clic en más. Lo que sucede es que trabajamos en el árbol de trabajo en progreso de una manera desconectada del entorno anfitrión, el navegador, hacemos cualquier actualización y luego la confirmamos. Y así es como sucede. Así que cuando hacemos clic en el botón, comenzamos el trabajo, por así decirlo. Y entonces llamas a begin work en el nodo más alto que es el main, y esto simplemente establecerá algunas flags, lo marcará como esto necesita actualizar o tal vez no. En este caso, no sé si lo hace porque su contenido está cambiando, pero de todos modos. Begin work establece algunas flags. Y cuando termina, se mete en el div, comienza el trabajo en el div. Lo mismo, marca cualquier actualización requerida. Solo dile a react cuál es el estado. Y luego cuando eso termina, entra en el hijo aquí, h1. Misma rutina. Comienza el trabajo, márcalo para actualizaciones, sigue adelante. Ahora, no hay hijos aquí. ¿Qué pasa? Completamos el trabajo. No hay hijos. No hay más hijos en los que entrar. Llamamos a una función llamada complete work y si no hay hermanos, volvemos al árbol. Si hay hermanos, vamos al hermano.

5. Entendiendo el Trabajo e Implementación de Fiber

Short description:

Completamos el trabajo en el árbol de fiber marcando el trabajo completo y moviéndonos al hermano. Después de completar el trabajo en los hijos, volvemos a la raíz. El trabajo completo construye un árbol desconectado de elementos DOM y conecta todo. El trabajo en progreso se pone en la pantalla usando el nodo raíz de fiber. Cuando el bucle de trabajo termina, cambiamos a la fase de compromiso, donde se ejecutan los efectos y se actualiza la UI. La implementación de Fiber se puede entender mirando el código y la estructura del árbol.

Completamos el trabajo aquí. ¿Cómo marco el trabajo completo? Simplemente voy a decir que el trabajo completo es volver por este camino. Y luego ir al hermano. Aquí al span. Comenzamos el trabajo en el span. ¿Tenemos hijos? ¿No los tenemos? Tenemos nodos de texto y esto probablemente está interpolado, así que esto cuenta como un hijo. Así que el trabajo inicial entrará allí, el trabajo completo porque no hay hijos, regresa, y simplemente caminamos. Caminamos, caminamos, caminamos. Y después de terminar con estos hijos, completamos el trabajo en los que aún no han completado el trabajo. Así que lo llamaremos trabajo completo y volveremos a la raíz. Ese es el ciclo.

¿Qué hace el trabajo completo? El trabajo inicial establece flags, el trabajo completo construye un árbol desconectado de elementos DOM, pero no en el navegador. Eso son props. Construye este árbol, construye, conecta todo. Y luego terminamos. Aquí es donde estamos. El siguiente paso es poner este trabajo en progreso en la pantalla. Para hacer eso, React tiene una estructura interna oculta llamada un nodo raíz de fiber. No ves esta cosa, pero existe. Y en el momento de montar tu aplicación, apuntará al árbol actual. Esto es antes de las actualizaciones. Este es el estado. Pero cuando el bucle de trabajo termina, cuando el trabajo completo termina en la última cosa, terminamos el trabajo de renderizado y cambiamos a la fase de compromiso. Nos comprometemos con el entorno anfitrión principal, el navegador, cambiando el puntero. Ahora eso es la fuente de verdad. Y también la fase de compromiso ejecutará cualquier efecto. Hay diferentes tipos de efectos. Hay efectos de host, que es literalmente como adjuntar los nodos dom al navegador. Hay efectos pasivos, que son tus llamadas a use effect y Así que los efectos se ejecutan, el nodo dom, tanto pasivo como de host efecto, todos se ejecutan en el compromiso y luego se actualiza tu UI. Así es como funciona Fiber. Por diagrama. ¿Genial?

¿Cómo funciona Fiber por código? Vamos, realmente no sé cómo voy con el tiempo. Simplemente miremos el código, lo que sea. No veo un reloj. Cuando enciendas un reloj, me detendré. ¿Cómo funciona esto en código? Abramos el código y lo que voy a hacer es literalmente abrir el código y haremos yarn parcel index. ¿Adivina qué? Construí esta aplicación de contador, esta de aquí, la construí como una demostración solo por diversión, ¿vale? Voy a abrir esto aquí y lo que tenemos es esto, que es literalmente lo mismo que esto. De hecho, si abrimos el código, ¿abrimos el código? Así que si abrimos el código, mira este árbol. Es literalmente main div, H1, span button. Es la misma estructura, ¿vale? Pero en código. Si has escrito React, esto parece familiar. Si lo abrimos ahora, está abierto. ¿Cómo lo abro? Vale. Esto funciona como se espera. Vamos a entrar en el código fuente de React DOM y jugar. Puedes decir que realmente no me gustan las diapositivas. Solo me gusta jugar. Así que lo que haremos es ir aquí. Literalmente nodo módulos. Uh-oh.

6. Explorando el Desarrollo de React DOM

Short description:

Vamos a profundizar en el desarrollo de React DOM. El código fuente está agrupado, pero es más fácil de leer en GitHub. Vamos a explorar el bucle de trabajo sincronizado y sus funciones. Perform unit of work almacena el estado y begin work envuelve otra función. La fibra actual se compara y nunca se modifica, mientras que la fibra de trabajo en progreso es con la que trabajamos.

Vamos a profundizar. ¿Dónde está react DOM? Ahí está. ¿Common JS? ¿Dónde está? React Desarrollo de DOM. Estamos aquí. Estamos aquí, todos. Hemos entrado. Mira esto. El número de regiones plegables está limitado a un máximo de 5,000. No es tan complejo. Está simplemente agrupado. El código fuente es mucho menos agrupado para las cosas. Es más fácil leer el GitHub.

Queremos empezar con el bucle de trabajo sincronizado. Eso es lo que teníamos en nuestro diagrama. Vamos a buscar con el comando F. Lo tenemos. ¿Qué hace esta función? Vamos a la definición. Así que mientras haya trabajo que hacer, hazlo. Es declarativo. Me encanta. ¿Qué hace eso? Vamos más profundo. Es como el tema del pez. Este pez, queremos encontrar el pez. Si crees eso, tuitea 'encuentra el pez'. De todos modos, perform unit of work. ¿Qué hace esto? Almacena algún estado. Si estamos en modo de perfil. No estamos en modo de perfil. Estamos en begin work. Vamos más profundo. ¿Qué es begin work? Es una función que envuelve a otra función. Vamos a esta. Begin work. Hemos llegado a la zona. Hay tres argumentos. Ese es el del entorno anfitrión. No tocamos esto. Lo pasamos alrededor. La fibra actual es la que enviamos aquí, la que enviamos allí. La comparamos. Nunca la modificamos. No es. Pero la fibra de trabajo en progreso es con la que trabajamos porque está en progreso. Así que empecemos por console. Log. Veamos una fibra. Todos, están a punto de ver una fibra. Trabajo en progreso. Hagámoslo. Ahora abramos esto.

7. Entendiendo Begin Work y Complete Work

Short description:

Vaya a la consola. Estamos trabajando en el nodo raíz de la fibra, que es la cosa oculta de la que hablamos. Begin work compara las viejas props con las nuevas props o los cambios de contexto y establece flags para las actualizaciones. Complete work sigue un proceso similar, y completamos el trabajo en el nodo raíz de la fibra.

Vaya a la console. Bueno, ahí lo tenemos. Permítanme aumentar el tamaño de la fuente para ustedes. En qué. El nodo de estado es en lo que estamos trabajando. Así que estamos trabajando en el nodo raíz de la fibra. Eso es esa cosa oculta de la que hablamos en el diagrama. Comenzamos a trabajar un nivel más bajo en el componente de la aplicación, uno más bajo en main. Así es como se ve una fibra, por cierto. El nodo de estado es el elemento real que es mutable. El nodo mutable. Puedes ver literalmente comenzar a trabajar y recorrer el árbol. Así que main, div, span. Comienza a trabajar bajando. Y veamos qué hace realmente begin work. Así que esto es una cosa interna de debug. No hablaremos de eso. Pero si el nodo actual no es nulo, es decir, si el nodo actual en el entorno del host existe, entonces ¿qué? Es una actualización. No una inserción. ¿Okay? Así que en el camino de la actualización, esto es lo que hace begin work. Comparamos las viejas props con las nuevas props o si ha cambiado el contexto. Establecemos algunas flags. Y si desplazo, solo estamos estableciendo flags, asegurándonos de que el reconciliador sabe que esto necesita actualizar o no necesita hacerlo. Eso es todo. A medida que desplazamos hacia abajo, tenemos un enorme switch case para diferentes tipos de componentes, componentes perezosos, componentes de función, componentes de clase, límites de suspense, etc., que simplemente los marca como que esto necesita actualizar. A medida que desplazamos más allá del gran switch case, eventualmente terminamos en un throw donde la unidad dice que no sabe qué estás tratando de hacer, pero no puede trabajar en esto. Y eso es begin work. Ahora veamos complete work. Volvamos a subir el árbol. Complete work, como notarás, la misma firma, render lanes es una preocupación de programación que está fuera del alcance de esta masterclass, así que no abordaremos eso. Todavía tenemos la fibra actual , la fibra de trabajo en progreso. Por posteridad, registremos este trabajo en la fibra de complete work . Y simplemente haremos un console log de la fibra de trabajo en progreso aquí. Y ahora cuando esto se recargue, veremos, oh mira, se volvió más complejo. Así que begin work. Begin work. Seguimos comenzando a trabajar hasta que llegamos a H1, ¿verdad? Ahora H1 no tiene hijos. H1 es un hermano. Si miramos el árbol DOM aquí, H1, no más hijos. Un nodo de texto, pero eso no es un elemento. Es solo texto. Así que comenzamos a trabajar en H1. Como puedes ver aquí, tipo de elemento H1. Y lo completamos de inmediato. Comenzamos a trabajar en el span, pero noten que hay más hijos aquí, porque eso es porque tengo esta interpolación aquí. Okay, así que se tratan un poco diferente. Pero comenzamos a trabajar, y si no hay hijos, completamos el trabajo. Y finalmente completamos el trabajo en el botón, el div, el main, el componente de la aplicación. Por último, también completamos el trabajo en el nodo raíz de la fibra. Y luego, aquí puedes ver, el nodo de estado es la fibra

8. Entendiendo Complete Work y la Fase de Compromiso

Short description:

Exactamente. Eso es esa cosa invisible. Ese switch es un puntero. Un componente de host es un componente en el entorno del host. Para React DOM, el entorno del host es el DOM. En un componente de host, propagas propiedades. Complete work construye el nodo DOM, lo adjunta al padre, lo mueve de nuevo hacia arriba. Luego cambiamos a la fase de compromiso llamando a commit root, que vacía los efectos pasivos y cambia el puntero.

nodo raíz. Exactamente. Eso es esa cosa invisible. Ese switch es un puntero. Así que hemos mirado, veamos qué hace complete work. Así que si volvemos aquí, es un enorme switch case de nuevo. ¿Verdad? Para todos estos tipos de componentes, propagar propiedades. Y eso es exactamente lo que suena. Y quiero centrarme aquí en una cosa específica llamada el componente de host. Un componente de host es un componente en el entorno del host. Para React DOM, ¿cuál es el entorno del host? Es el DOM. El navegador. En un componente de host, ¿cómo completas el trabajo? Así es como. Propagas propiedades. Verificas si fue hidratado desde server side rendering. Pero en este caso, no es así. Solo estamos en el lado del cliente renderizando. Cambiaremos a la otra rama. Ve aquí. Y la instancia es create instance. ¿Sabes lo que es eso? Vamos un nivel más profundo. Create instance es esencialmente un documento que valida algunas anidaciones y llama a create element. Y ahora estamos en lo que hace complete work. Básicamente está creando un elemento fuera, como separado de el navegador, pero aún está construyendo un árbol. Complete work construye el nodo DOM, lo adjunta al padre, lo mueve de nuevo hacia arriba. Vale. Solo recorre el árbol. Y puedes ver eso. Añadimos todos los hijos, establecemos el nodo de estado en la instancia, y marcamos algunas actualizaciones, etc., y simplemente seguimos en el switch case. Complete work finalmente llega a la raíz y la renderización ha terminado. Luego cambiamos a la fase de compromiso. Ponemos cosas en la pantalla. Cambiamos. Si volvemos al diagrama, lo que es la fase de compromiso, si recuerdas, es cambiar el puntero, así. ¿Cómo cambiamos el puntero? Hay una función llamada commit root. Sí, esa es. Vamos a profundizar en esto y ver. Lo que quiero hacer es console.log, commit root. Y registraremos la raíz aquí, pero preferiblemente así. Guardar. Así que ahora ves, hemos comprometido la raíz. Literalmente solo cambia el puntero. Este es el nodo raíz de la fibra que estás viendo. Cada vez que llamo a esto, simplemente hace lo mismo una y otra vez muy, muy rápido. ¿Qué hace commit root? Vacía los efectos pasivos. Un efecto pasivo, mira, hay incluso una explicación aquí. Un efecto pasivo no es un efecto de host No es como adjuntar cosas al DOM. En los efectos de host, hay diferentes tipos. Hay un efecto de inserción, hay un efecto de colocación, hay un efecto de actualización, estos efectos literalmente implican mutar el DOM y hay efectos pasivos que son efectos de componente cero. Así que vaciamos esas cosas, marcamos algunos eventos, y finalmente cambiamos el puntero aquí.

9. Internos de React y Entendiendo el Código

Short description:

Así que simplemente ejecutamos, hay muchos efectos en ejecución, realmente, muchos efectos se están confirmando. Pero en algún momento verás que cambiamos los árboles del actual al trabajo en progreso. Los internos de React son complejos, pero los externos son poderosos debido a eso. Entender los internos me ha ayudado en casos de revisiones de solicitudes de extracción donde tenemos debates o algo. Me alejo de las micro-optimizaciones porque sé lo que está pasando. Ayuda a informar cuánto optimizo.

Así que simplemente ejecutamos, hay muchos efectos en ejecución, realmente, muchos efectos se están confirmando. Pero en algún momento lo que verás es que cambiamos los árboles del actual al trabajo en progreso. Y también llamamos a un hook. Cuando termina, ¿qué pasa? Eventualmente, marcamos la confirmación como detenida, y termina donde terminan todas las últimas cosas. Así que lo que quiero mostrarte con esto es, uno, cómo funciona con el bucle, pero también que hay muchos casos límite, hay muchas cosas que React resuelve por ti que no necesitas resolver tú mismo, y esa es toda la propuesta de valor, ¿cómo hacemos actualizaciones a la UI de una manera rápida, de una manera predecible, y de una manera que nos permite simplemente construir aplicaciones rápidas, sin preocuparnos demasiado con los internos. ¿Eso está bien? Muy bien. Hablemos de mi conclusión. ¿Qué podemos llevarnos de esta charla? Podemos llevarnos que los internos de React son complejos, pero los externos son poderosos debido a eso. Como, podemos construir todos esos casos límite, esos grandes switch cases que viste, nuestro trabajo que el equipo hace en nuestro nombre, para que no tengamos que hacerlo, para que React pueda tener un ambiente realmente bueno para construir aplicaciones de manera poderosa y rápida. Dicho esto, los internos son divertidos. Y mi única conclusión para ti es recordar, oye, escucha, React, he oído a mucha gente decir que React es demasiado difícil o demasiado complejo, como los internos. Toda esta charla que preparé fue leyendo el código fuente en GitHub porque es de código abierto y tratando de participar, y de hecho, ahora estoy participando, supongo, hablé con algunos del equipo que son muy acogedores y de apoyo, y es un ecosistema. Así que mi conclusión es, estoy agradecido de ser parte de este ecosistema y espero que te sientas alentado a hacerlo también. React Advanced London, gracias muchísimo por el tiempo. Gracias, gracias, gracias. Por favor, deja tu portátil y sígueme a la sala de interrogatorio. Uh-oh. Sí. Estoy a punto de ser interrogado. Estás en problemas, joven. No, gracias, eso fue una inmersión profunda. Realmente estás cumpliendo con tus promesas y el nombre de esta conferencia. ¿Soy un pez? ¿Eres un pez? ¿Quieres ser un pez? ¿Ser un pez es algo bueno? Hay un superhéroe en este show llamado The Boys que es un pez. The deep, de todos modos. Sí, yo, Aquaman está infravalorado es mi opinión. Esa es mi opinión. ¿Deberíamos hablar más de eso? No, está bien. Vamos a las preguntas de la audiencia. La primera pregunta de la audiencia es, ¿de qué manera has descubierto que una comprensión más profunda de React bajo el capó ha informado o cambiado el código que escribes? Me gusta mucho esto. Me gusta mucho esto. Así que en pequeñas formas. Y no puedo enfatizar lo suficiente cuán importante es no preocuparnos demasiado con los internos. Hay personas bien pagadas para hacer eso por nosotros, ¿verdad? Y así lo hacen bien por nosotros para que no tengamos que hacerlo, y el enfoque es usar React. Y ese es el enfoque. No necesariamente entender los internos. Pero entender los internos me ha ayudado en casos de revisiones de solicitudes de extracción donde tenemos debates o algo, podemos realmente mirar el código y puedo enseñar y mentorizar. Creo que ayuda. Pero también, me alejo de las micro-optimizaciones porque sé lo que está pasando. Como, no necesito poner todo en used memo. No necesito hacer todos mis componentes perezosos. Como, ayuda a informar cuánto optimizo porque sé cuánto se está optimizando para mí detrás de las escenas, así que. Por supuesto. Quiero añadir mi propia pregunta a eso. Recuerdo cuando solíamos trabajar con herramientas más sencillas que no eran tan poderosas, pero también eran más sencillas. En un momento, creo que recordaba la mayor parte del código fuente de backbone de memoria. Ahora con estas herramientas que usamos ahora, la complejidad es demasiado para un programador de producto en funcionamiento para mirar. Entonces, ¿cuánto crees que es importante a medida que te vuelves, digamos, más senior en la organización tener a una persona en el equipo que entienda estas herramientas? ¿O es simplemente una pérdida de tiempo? No sé si es una pérdida de tiempo, porque creo que una parte importante de ser un ingeniero senior es la capacidad de mentorizar. Hay una sala de habilidades blandas, ¿verdad? Realmente quiero asistir a eso porque siento que eso es en realidad más importante que el código en sí a veces. Y así creo que si hay al menos una persona que tiene un verdadero conocimiento profundo allí, pueden usarlo para educar e informar. Y hay muchos patrones en esta base de código de los que puedo aprender personalmente.

10. React 18 y el Bucle de Trabajo

Short description:

Las funciones de bucle de trabajo sincrónico y bucle de trabajo asíncrono en React 18 facilitan las características concurrentes y un sistema de prioridad. Aunque el código mostrado todavía está en React 18 y no ha cambiado, el bucle de trabajo asíncrono puede convertirse en el predeterminado en el futuro. Si un elemento se elimina directamente a través del objeto del documento, puede provocar problemas con el reconciliador de React. Se recomienda utilizar refs en su lugar. XcaliDraw es la herramienta de dibujo utilizada, pero existen otras alternativas excelentes como tlDraw y stately.ai.

Solo por ejemplo, ¿verdad? Esta función llamada bucle de trabajo sincrónico. Mientras haya trabajo por hacer, hazlo. Esta forma de estructurar code es algo que puedo aprender y luego enseñar a mi equipo. Así que no creo que sea inútil. También creo que si eres una empresa en esta economía, es algo bueno de tener. Pero no creo que sea obligatorio. Genial. La siguiente pregunta más votada es, ¿cambió algo en este algoritmo React 18? Esa es una buena pregunta. Lo que estaba usando, estoy bastante seguro, era React 18. ¿Es React 18 la última etiqueta? Eso era React 18, así que no tal vez, pero hay un... Así que había un bucle de trabajo sincrónico del que hablé. También hay un bucle de trabajo asíncrono. Esa es la característica concurrent. Y eso utiliza, hasta donde yo sé, esto es donde se vuelve incierto, pero eso utiliza un programador bajo el capó que literalmente calculará cuál es una actualización de alta prioridad, cuál no, y todo el punto de Fiber es ser interrumpible. Así que cambiar de bucle de trabajo sincrónico a bucle de trabajo asíncrono facilitará muchas de estas características concurrent donde ahora hay un sistema de prioridad y un programador para esos. El code que mostré todavía está en React 18 y no ha cambiado, pero en algún momento, sospecho, el bucle de trabajo asíncrono será el predeterminado y el bucle de trabajo sincrónico será la opción de respaldo. Sí, esperemos que el próximo año podamos tenerte de vuelta y puedas dar una charla sobre el programador asíncrono. Sí. Creo que esa es la parte para mí que todavía es un poco de magia negra. Entiendo que funciona, pero no estoy realmente seguro de cómo en absoluto. Me está dando ideas para mi próxima charla. ¿Quieres ver eso? No. No. Yo tampoco. Yo tampoco. Pero ese era ese chico. Deberías hablar con él después. Sí. Muy bien, pregunta principal. Vamos por orden democrático. Esto parece casi como una pregunta de entrevista de trabajo. Si un elemento es eliminado por un objeto de documento directamente, así que asumo que manipula el DOM, ¿existe la posibilidad de causar una fuga de memoria ya que el Fibre mantiene la referencia? No sé cómo Fibre mantiene las referencias. No he investigado eso, pero sí. Conoces el reconciliador de pila antes del Fibre. Así es como solía ser, ¿verdad? Las cosas se mutan sobre la marcha. El problema con eso es que no puedes abandonar algo a mitad de camino. Si solo actualizas la mitad del DOM, y dices, llegó una actualización de mayor prioridad, ¿qué haces? No puedes revertirlo. ¿Deberías revertirlo? No puedes. Así que se complica. Así que si un elemento es eliminado a través del objeto del documento directamente, básicamente vuelves a React como pre-16, que hay una razón por la que eso fue deprecado. Y creo que si el elemento es mantenido por React mismo, creo que el próximo bucle de trabajo será añadido o se bloqueará de una manera indefinida. Así que probablemente sea una mala idea, y no deberías hacer eso. Usa refs. Sí. Esa es parte del trabajo completo, así como la actualización de refs. Genial. Pregunta principal, por supuesto, no qué fuente usaste, sino ¿cuál es el nombre de la herramienta de dibujo que usaste? XcaliDraw, lo usé porque me gusta, pero grandes alternativas, tlDraw, gran herramienta. Sí, tenemos un tl, y también stately.ai para diagramas. Excelente. Realmente, no nos faltan herramientas increíbles aquí.

11. Diferencias y Beneficios de Fiber

Short description:

Fiber aporta varias diferencias sobre las antiguas heurísticas de reconciliación. Permite la renderización asíncrona, la programación y la capacidad de hacer trabajos a medias y descartar árboles de trabajo en progreso. Esto no era posible con el reconciliador de pila anterior, que a menudo causaba que las actualizaciones de baja prioridad bloquearan la entrada del usuario.

Genial. Tenemos tiempo para una o dos preguntas más. Permíteme tomar esta. ¿Qué diferencias aporta Fiber sobre las antiguas heurísticas de reconciliación? Quiero decir, supongo que la capacidad de hacer renderización asíncrona y todo eso es algo del futuro, pero ¿hay algo más que te gustaría añadir? Creo que la programación, realmente. Esto es algo grande. Como, la capacidad de hacer trabajos a medias y luego descartar un árbol de trabajo en progreso, eso es genial. Nunca podrías hacer eso antes. No había forma de hacer trabajos a medias, y entonces, porque no podías hacer trabajos a medias de la manera anterior, el reconciliador de pila, que creo que es la pregunta. Olvidé la pregunta. Estoy improvisando. No puedes hacer trabajos a medias, así que lo que sucedería era una actualización de muy baja prioridad, como alguna cosa de imagen que quizás no era importante bloquearía un problema de entrada del usuario. Y luego Dan Abramov dio esta charla en JSConf Iceland sobre CPU-bound y I O-bound, y yo estaba como, guau, eso es increíble. En fin. Genial. Bien. Hagamos una pregunta final. Creo que tenemos un par de preguntas sobre el mismo tema. Creo que esta es una pregunta muy razonable dado el cambio general de terminología. Entonces, ¿cómo encaja el concepto de DOM virtual en este tipo de cosa de Fiber? ¿Es Fiber el DOM virtual? ¿Cuál es la relación entre estos dos términos? Esa es una buena pregunta. Hasta donde yo sé, conocimiento falible. Hasta donde yo sé, el DOM virtual es solo un virtualizado... es solo como una data estructura. Es solo un... es una representación clonada de tu DOM pero para que una biblioteca haga lo que quiera con él y luego, ya sabes, seguimiento de cambios y diferenciación y todo eso es aparte hasta donde yo sé. Genial. Bueno, eso es todo el tiempo que tenemos para el escenario. Pero cualquiera que quiera hablar con Tejas puede encontrarlo en los pasillos o en la sala de preguntas y respuestas de los oradores donde también puedes unirte a través del chat espacial si nos estás acompañando de forma remota. Muchas gracias, Tejas. Demos a Tejas un último gran aplauso.

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

A Guide to React Rendering Behavior
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Concurrent Rendering Adventures in React 18
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn