Dentro de Fiber: Una Visión General del Algoritmo de Reconciliación de React

Hola a todos, mi nombre es Elad Zamek y soy un desarrollador de software en Viva Systems en Toronto, Canadá. Viva ofrece productos basados en la nube para la industria global de ciencias de la vida y actualmente trabajo allí como desarrollador de UI principal para el producto Safety AI.

Hoy hablaremos sobre Fiber, el nuevo algoritmo de reconciliación de React que se introdujo en React 16. Hablaremos sobre lo que React tenía antes de Fiber, por qué era necesario Fiber y algunas de las cosas que podemos lograr con Fiber. Tenemos mucho que cubrir, así que empecemos.

Comenzaré con una demostración rápida aquí y como pueden ver, tengo una aplicación bastante simple que tiene un campo de entrada. Todo lo que escribo en el campo de entrada se muestra. Tenemos 80 elementos en una lista que se muestra con el valor que escribimos en el campo. Si escribo mucho, obtendremos 80 elementos con el texto 'mucho'. Mi lista lenta es un componente que se renderiza. Si entramos en él, podemos ver que nos devuelve un array de 80 elementos del componente de elemento de lista, que es un componente que espera tres milisegundos y luego devuelve un elemento LI con el texto que pasamos. La razón por la que espero aquí tres milisegundos es simplemente para simular un componente que es pesado y que tarda mucho tiempo en renderizarse porque es muy complejo.

Ahora, si escribo algo en el campo de entrada, digamos que voy a escribir React conference, escribo y dejo de escribir ahora y luego puedo ver el valor en el campo de entrada y en la lista. Así que lo haré de nuevo, React conference, dejo de escribir ahora y luego lo veo. Espero que hayas notado ese retraso que tuve. Fue como de un segundo o dos, entre el momento en que terminé de escribir React conference en el campo de entrada, y el momento en que vi el valor que se estaba llenando en el campo de entrada mismo y se estaba renderizando en la lista. Y eso se debe a que cuando escribí el valor, tenía otro componente, el componente MySOLIST que se renderizaba mientras lo escribía. Y estoy seguro de que, al igual que la mayoría de ustedes al menos, han visto este tipo de problema en sus aplicaciones donde tienen un campo de entrada lento porque hay otro componente pesado y complejo que necesita ser renderizado según el valor que tienes en el campo de entrada o algo similar a eso.

Entonces veamos nuestra aplicación solo para poder entender por qué está sucediendo esto. Y lo vamos a ver en forma de un árbol conectando todos los componentes y ver qué está sucediendo. El reconciliador de pila es la implementación que impulsa a React 15 y versiones anteriores. No entraré en demasiados detalles sobre cómo funciona este algoritmo porque estamos aquí para hablar del algoritmo Fabry. Pero lo importante de saber es que, por ejemplo, el estado de la aplicación ha cambiado. React recorrerá este árbol de componentes de forma recursiva preguntando a cada componente cómo, ¿qué estás renderizando en función de ese cambio de estado? Luego, en función del resultado de la función de renderizado, creará un DOM virtual y actualizará el DOM con ese resultado. Por lo tanto, este algoritmo de reconciliación es un algoritmo puramente recursivo. Una actualización resulta en que todo el subárbol se vuelva a renderizar de inmediato. Si bien esto funciona bien, tiene algunas limitaciones. Aquí puedes ver que el elemento de entrada en azul es el que requiere una respuesta rápida para nosotros. Queremos que el usuario vea lo que escribe mientras lo escribe. Sin embargo, dado que la escritura actualiza el estado de todo el componente de la aplicación, todo se renderiza, incluida esa lista lenta en rojo y por eso todo parece tan lento.

Entonces, ¿qué es realmente lo incorrecto con este reconciliador de pila? Tengo una cita aquí de Andrew Clark, quien es uno de los miembros del equipo principal de React en Facebook. En la interfaz de usuario, no es necesario que cada actualización se aplique de inmediato. De hecho, hacerlo puede ser ineficiente y provocar caídas de frames y degradar la experiencia del usuario. Ahora, con el antiguo algoritmo de reconciliación, no podíamos dividir el trabajo en unidades incrementales. Si React iba a recorrer todo el árbol de componentes de forma síncrona y realizar el trabajo para cada componente, podría superar los 60 milisegundos disponibles para que el código de la aplicación ejecute su lógica.

Ahora, ¿qué queremos decir cuando nos referimos a 60 milisegundos y por qué es un problema con el enfoque recursivo? Bueno, típicamente, para que un video se sienta fluido e instantáneo para el ojo humano, el video debe reproducirse a una velocidad de aproximadamente 30 cuadros por segundo. Cualquier cosa por encima de eso brindará una experiencia aún mejor. Y esta es en realidad una de las principales razones por las que los jugadores prefieren una mayor frecuencia de cuadros para los juegos de disparos en primera persona donde la precisión es muy importante. Dicho esto, la mayoría de los dispositivos en estos días se refieren a sus pantallas a 60 cuadros por segundo, o en otras palabras, con 60 cuadros por segundo, se muestra un nuevo cuadro cada 16 milisegundos. Este número es muy importante porque si el renderizado de React tarda más de 16 milisegundos en renderizar algo en la pantalla, el navegador descartará ese cuadro y el usuario experimentará una experiencia lenta similar a la que vimos anteriormente. No sé si alguna vez has visto un video que se creó con 12 FPS o 10 FPS o 20 FPS, pero no es tan fluido como 30 y definitivamente no como 60 FPS.

Otra cosa importante a tener en cuenta es que JavaScript es un lenguaje de un solo hilo. Y debido a que el código de JavaScript se ejecuta en un solo hilo, solo se puede ejecutar una línea de JavaScript a la vez. El mismo hilo también es responsable de otros ciclos de vida del documento, como el diseño y la pintura. Y esto significa que cada vez que se ejecuta el código de JavaScript, el navegador se bloquea y no puede hacer nada más. Si React va a recorrer todo el árbol de componentes de forma síncrona y realizar el trabajo para cada componente, como dijimos, podría superar esos 16 milisegundos disponibles. Y como los navegadores solo tienen esos 16 milisegundos para hacer todo el trabajo, para funcionar a 60 FPS, reaccionar a cada uno de esos eventos puede bloquear por completo tu aplicación de JavaScript cuando no cumplimos con ese presupuesto de 16 milisegundos. Esencialmente, es cuando vemos que el contenido de tu aplicación web se mueve de manera entrecortada en la pantalla. A menudo se le llama tartamudeo. Nuevamente, lo que vimos en nuestra demostración. Y, por supuesto, afecta negativamente la experiencia del usuario.

Ahora podrías pensar, ¿por qué no hacer que React sea más rápido? Bueno, el problema en la demostración que vimos, por ejemplo, fue que en las actualizaciones, como la entrada del usuario se quedaba atrás de las actualizaciones más grandes, como el árbol de componentes complejo, esa lista lenta. Ese es código del usuario, no es parte de React en sí. Entonces, con todo lo que expliqué hasta ahora, podemos formular dos problemas que debemos resolver para obtener interfaces de usuario más receptivas. El primero es que las tareas de larga duración causan caídas de frames. Y necesitamos asegurarnos de que todas nuestras tareas sean pequeñas y se puedan completar en un par de milisegundos para poder ejecutarlas en un solo frame. Y luego el segundo es que diferentes tareas tienen diferentes prioridades. Así que introduzcamos el modo concurrente. Es experimental y es un conjunto de nuevas funciones que ayudan a que las aplicaciones de React sean receptivas y se ajusten de manera elegante a las capacidades del dispositivo del usuario y a la velocidad de la red. Debido a que es experimental, las cosas pueden cambiar. No se recomienda utilizarlo en producción por el momento, excepto en Facebook donde se utiliza en producción. Y si quieres más detalles, te recomendaría encarecidamente que consultes la documentación oficial de React.

Y acabamos de notar que JavaScript es de un solo hilo. Entonces, ¿cómo puede ser concurrente? Bueno, se trata principalmente de hilos conceptuales o, en términos más precisos, de programación cooperativa o concurrencia cooperativa. Básicamente, lo que todos estos términos elegantes significan es que una vez que se le da el control al hilo, continúa ejecutándose hasta que cede el control explícitamente o se bloquea. Entonces, ¿qué significa esto? Tomemos como ejemplo los sistemas de control de versiones. Antes de los sistemas de control de versiones, como se puede ver a la derecha, si queríamos trabajar en una función, teníamos que asegurarnos de que nadie más estuviera modificando los archivos en los que estábamos trabajando, teníamos que informar a todos que estábamos trabajando en esos archivos. Básicamente, estábamos bloqueando a todos los demás para que no hicieran cambios en esos archivos mientras los estábamos modificando. Y esto se puede considerar como un proceso síncrono. Cuando aparecieron los sistemas de control de versiones, simplemente se creaba una rama de función, se hacía el trabajo y luego se fusionaba de nuevo. Y esto se puede considerar como un proceso asíncrono.

Entonces, React Fiber elimina esencialmente la necesidad de procesar actualizaciones de manera recursiva y sincrónica. En cambio, permite que React aproveche la programación y priorización, lo que nos permite pausar el trabajo y reanudarlo más tarde, asignar diferentes prioridades a diferentes tipos de trabajo y reutilizar o descartar el trabajo calculado previamente. Por ejemplo, en nuestra demostración, React podría mantener el campo de entrada receptivo para el usuario, lo que significa que el usuario vería lo que está escribiendo de inmediato, ya que tendría una prioridad más alta que la lista de elementos que deben renderizarse. Luego, cuando el usuario no hace nada, es decir, no bloquea el hilo principal, React puede renderizar y mostrar esa lista de elementos.

Entonces, eso suena genial, ¿verdad? Bueno, veámoslo en acción. Esta es la misma aplicación que teníamos antes. La única diferencia es que importamos el hook useDeferredValue aquí y le pasamos la variable de estado de texto junto con un objeto con el tiempo de espera establecido en 2000 milisegundos, que es igual a dos segundos. Ahora, estamos pasando la variable de estado de texto a nuestro campo de entrada porque queremos estar actualizados con lo que estamos escribiendo, pero a MySlowList le estamos pasando esa variable de texto diferido, porque, bueno, ya lo verás. Ahora, escribiré React Conference nuevamente y realmente no puedes verlo, pero a medida que escribo, veo los caracteres que se escriben en el campo. Pero la lista se está quedando atrás en cuanto a lo que se renderiza. Lo haré de nuevo. Como puedes ver, terminé de escribir y ahora la lista se está poniendo al día lentamente en la renderización, ¿verdad?

El hook useDeferredValue envuelve un valor de prop o estado y recibe el tiempo máximo de espera diferido. Esto básicamente le dice a React que está bien que los componentes que dependen de este valor se rendericen en un momento posterior. Se utiliza comúnmente para mantener la interfaz receptiva cuando tienes algo que se renderiza de inmediato según la entrada del usuario, como en nuestra demostración aquí. Por ejemplo, con este código, básicamente decimos que necesitamos mostrar el texto en el campo de entrada tan pronto como el usuario lo escriba. Necesitamos ver exactamente lo que escriben, pero cuando se trata de la lista, está bien si tarda hasta dos segundos en ponerse al día con lo que necesita renderizar.

Entonces, entendamos qué es un objeto Fiber, no el algoritmo, los objetos. Un Fiber también es un objeto JavaScript que contiene información sobre un componente, su entrada y su salida. También corresponde a una instancia de un componente. Hay muchos campos en FiberNode, esta no es una lista exhaustiva en ningún sentido, pero solo para darte una idea general, puedes ver que hay información sobre los hijos del componente, si tiene hermanos, actualizaciones pendientes, props pendientes, estado pendiente, prioridad de trabajo y mucho más. En cuanto al algoritmo Fiber, tiene dos fases, reconciliación y confirmación. La reconciliación es interrumpible, lo que significa que podemos pausarla y reanudarla cuando queramos, y la confirmación no es interrumpible, lo que significa que una vez que la iniciamos, no podemos detenerla. Tenemos que dejar que termine. Durante el renderizado inicial, cada elemento de React que se devuelve desde la llamada a la función de renderizado se convierte en un Fiber. Y cuando un elemento de React se convierte en un nodo Fiber por primera vez, React utiliza ese dato, ese Fiber que se creó a partir de la llamada. Básicamente, el elemento de React se convierte en un Fiber y luego ese Fiber se coloca en un árbol que se llama current. Aquí puedes ver un ejemplo específico para el elemento de entrada, pero esto, por supuesto, también ocurre para todos los demás nodos en el árbol actual.

El elemento React se convierte en un Fibre, que se utiliza para construir el árbol actual. Este árbol es esencialmente la representación actual del estado de la interfaz de usuario que debe renderizarse. ¿Y se renderizará, verdad? En el primer renderizado cuando cargamos nuestra aplicación.

Ahora hablemos de las actualizaciones. Cuando React comienza a trabajar en las actualizaciones, por ejemplo, un cambio de estado, construye un árbol de trabajo en progreso que refleja el estado futuro que se debe mostrar en la pantalla según esa actualización. Como puedes ver en este caso, tiene los mismos Fibres que el árbol actual. Pero digamos que con este elemento de entrada aquí, podemos ver a la izquierda con el árbol actual, hay una etiqueta de efecto cero, lo que significa que no hay ninguna actualización y el valor es una cadena vacía. Pero a medida que escribimos, por ejemplo, si escribimos `alive`, la primera letra es `E`, obtendremos un Fibre con una etiqueta de efecto cuatro, lo que significa que hay una actualización pendiente y el valor que tendrá es `E`. Todo el trabajo de actualización de estado y props se realiza en los Fibres del árbol de trabajo en progreso. A medida que React recorre el árbol actual para cada nodo de Fibre existente, crea un nodo alternativo y todos estos nodos constituyen el árbol de trabajo en progreso. La razón por la que necesitamos el árbol de trabajo en progreso es porque no queremos realizar cambios en el DOM mientras estamos calculando los cambios, a diferencia del reconciliador de pila. Nuevamente, esta diapositiva muestra un ejemplo de cómo se actualiza nuestro elemento de entrada, pero lo mismo ocurre con todos los demás Fibres que tienen alguna actualización. El árbol de trabajo en progreso contiene los estados y props más actualizados para cada componente, pero aún no se ha mostrado en la pantalla. Pero espera, ¿contiene toda la información más actualizada de cada componente? Bueno, no realmente, porque si recuerdas en nuestra demostración, le dijimos a React que está bien retrasar el cálculo de la lista lenta como máximo dos segundos. Eso significa que otros cálculos, como para nuestro elemento de entrada, tendrán prioridad y se ejecutarán en el hilo principal, mientras que otros trabajos de menor prioridad, como el componente MySlowList en este caso, se encolarán para más tarde porque tiene una prioridad más baja. Solo después de que se haya completado el trabajo de alta prioridad y se haya mostrado en la pantalla, solo cuando hayamos terminado de escribir, porque ese es el trabajo de alta prioridad, entonces React pasará al trabajo de menor prioridad y lo calculará. Y nuevamente, ese es el componente MySlowList. Entonces, React ha procesado el componente de la aplicación y sus hijos, excepto MySlowList. Y ahora ha terminado con la fase de renderizado, la fase de reconciliación. A la derecha está el nuevo árbol que debe mostrarse en la pantalla. Se puede procesar inmediatamente después de la fase de renderizado o la fase de reconciliación, es lo mismo, o se puede retomar más tarde cuando React tenga tiempo por parte del hilo principal del navegador. En nuestro caso, dado que aún no han pasado los dos segundos, digamos que React tiene tiempo para confirmar estos cambios en la pantalla. Y, por supuesto, estos cambios son nuestra escritura en el campo de entrada. Uno de los principios fundamentales de React es la consistencia. React siempre actualiza el DOM de una vez, no muestra resultados parciales, ¿verdad? El árbol de trabajo en progreso sirve como un borrador que aún no es visible para el usuario, para que React pueda procesar todos los componentes primero y luego aplicar los cambios en la pantalla. Es importante entender que el trabajo durante esta primera fase, la fase de reconciliación, se puede realizar de forma asíncrona. React puede procesar uno o más nodos de Fibre según el tiempo disponible, luego detenerse para guardar el trabajo realizado y ceder a algún evento de mayor prioridad si lo hay. Luego continúa desde donde lo dejó. Pero a veces, puede ser necesario descartar el trabajo realizado y comenzar desde el principio. Estas pausas son posibles debido a que el trabajo realizado durante esta fase no conduce a cambios visibles para el usuario, como actualizaciones del DOM. En contraste, la segunda fase, la fase de confirmación, siempre es síncrona.

Y, por supuesto, eso se debe a que el trabajo realizado durante esta fase conduce a cambios visibles para el usuario, como actualizaciones del DOM, y es por eso que React tiene que hacerlo de una sola vez. No podemos pausar, mostrar resultados parciales y luego reanudarlo. Tiene que hacerse de una sola vez.

Entonces, la fase de confirmación. Actividades como la mutación del DOM o llamar a los métodos del ciclo de vida se consideran efectos y se almacenan en la lista llamada lista de efectos. En nuestro ejemplo, las propiedades tanto del campo de entrada como de la aplicación cambian. Por lo tanto, sus efectos correspondientes se almacenan aquí en esta lista. Y React, esencialmente, en la fase de confirmación, recorrería esta lista y realizaría los cambios en el DOM. Así que, si recuerdas el campo de entrada, necesitamos cambiarlo porque estamos mostrando algo en ese campo de entrada. Pero también, el estado de la aplicación, también necesitamos cambiar su estado. Entonces, ambos componentes, esos elementos, tienen efectos esperando ser confirmados en el DOM.

Esto también significa que, después de que se haya realizado todo este trabajo, el árbol de trabajo en progreso tiene una versión más actualizada del estado de la aplicación, ¿verdad? Entonces, React también intercambia los punteros raíz del árbol actual y el árbol de trabajo en progreso, intercambiando efectivamente el árbol actual con un árbol provisional que construyó en función de la actualización de estado que tuvimos.

Para concluir, si recuerdas, al principio de la presentación, formulé dos problemas que debemos resolver para obtener interfaces de usuario más receptivas. El primero era que las tareas de larga duración causan caídas de frames. Y el segundo era que las diferentes tareas tienen diferentes prioridades. Abordamos esto utilizando el hook useDeferredValue, que aprovecha el algoritmo de Fiber y asigna una prioridad diferente a cada tarea, resolviendo así nuestro problema de caída de frames que tuvimos al principio de la presentación. También es importante mencionar nuevamente que estas características del modo concurrente aún no están disponibles en la versión estable. Y para usarlas, tendrías que instalar una versión experimental de React, lo cual, por supuesto, no se recomienda utilizar en producción, ya que aún hay algunos errores y características faltantes.

Entonces, Fiber mejorará las aplicaciones de React a corto plazo al permitir que las actualizaciones de alta prioridad se adelanten a las actualizaciones de baja prioridad. Y lo hace dividiendo el trabajo en pequeñas unidades llamadas Fibers, que pueden pausarse y reanudarse más tarde. Hay mucho más de qué hablar y mencionar cuando se trata de cómo funciona Fiber. Así que, si estás interesado en Fiber y todas las características experimentales del modo concurrente, te animo encarecidamente a que leas más al respecto. La documentación oficial de React es un gran recurso, al igual que explorar el código de React en sí. Espero que esta presentación te haya dado una buena idea de lo que es posible con Fiber y te haya emocionado un poco por el futuro. Personalmente, creo que la combinación de Fiber y el modo concurrente ofrece un futuro muy prometedor para React, donde como desarrolladores podemos lograr cosas que antes no podíamos y, con eso, permitir una mejor experiencia de usuario en nuestras aplicaciones. Con eso, me gustaría agradecerles a todos por escuchar y disfruten el resto de la conferencia.