Entendiendo la Arquitectura Fiber de React

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.

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.

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í.

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.

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.

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.

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

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.

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í.

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.