Manteniéndose seguro en un mundo concurrente

Espero que estén teniendo una conferencia increíble hasta ahora. Tal vez incluso hayan escuchado un par de charlas mencionando las nuevas características concurrentes que se lanzaron en React 18 hace un par de meses. En esta charla, no vamos a entrar en detalles sobre cómo funcionan estas características y qué hacen, pero queremos analizar las implicaciones y ramificaciones que esas características tienen en nosotros como desarrolladores para poder mantenernos seguros en un mundo concurrente de React.

Antes de adentrarnos en eso, permítanme contarles un poco sobre mí. Mi nombre es Andreas y soy de Dresden, Alemania, donde soy líder de desarrollo en una pequeña agencia de software. Nuestro trabajo consiste en ir a otras empresas de desarrollo de software y ayudar a los equipos a acelerar sus proyectos de software. Lo hacemos utilizando tecnologías como TypeScript React. Así que esto es exactamente lo que hago todos los días.

En este trabajo, lo que nos dimos cuenta en los últimos meses es que hay mucho miedo, incertidumbre y duda debido al nuevo lanzamiento de React y las nuevas reglas y lo que hay que hacer para estar seguro en el modo concurrente en sus aplicaciones. Y por eso propuse esta charla, para que puedan relajarse y mantenerse seguros en un mundo concurrente.

Cuando retrocedemos un par de años, hasta 2018, Abramov introdujo el renderizado asíncrono. Por lo tanto, React debería adaptarse al dispositivo del usuario, las interacciones rápidas deberían sentirse instantáneas y las interacciones lentas deberían sentirse receptivas. La técnica principal consistía en dividir el proceso de renderizado para poder pausar, reanudar, realizar diferentes actualizaciones, de modo que nuestra aplicación se mantenga rápida y receptiva, sin importar el dispositivo o las condiciones de la red.

Desde entonces, muchas cosas han cambiado. Por ejemplo, la fecha de lanzamiento se ha retrasado un poco y el nombre ha cambiado de renderizado asíncrono a renderizado concurrente o modo concurrente. Y luego, con React 18, el equipo tomó la increíble decisión de no introducir un modo concurrente que cambie toda su aplicación a este nuevo mundo concurrente, sino que introdujo características concurrentes para que pueda optar por partes pequeñas de su aplicación en las características concurrentes, de modo que no toda su aplicación tenga que estar lista para el modo concurrente, sino solo partes de su aplicación.

Incluso lanzaron una publicación en el blog en ese momento, donde realizaron ciertos cambios en la API de React para preparar este cambio para el futuro. Eliminaron los métodos `componentWillMount`, `componentWillReceiveProps` y `componentWillUpdate`, o los reemplazaron por variantes inseguras. Esto es para que ustedes, como desarrolladores, sepan que estos métodos no son realmente seguros de usar con características concurrentes, pero aún pueden estar en su código siempre y cuando no utilicen las características concurrentes. Podría decirse que las reglas de React han cambiado desde entonces. Pero no es cierto. Las reglas de React no han cambiado desde entonces. Este es el punto más importante de mi presentación. Las reglas de React no han cambiado. Solo ahora estamos comenzando a aprovechar realmente las mismas reglas que estuvieron presentes desde hace mucho tiempo.

Encontré este documento de diseño que establece los conceptos y los modelos mentales alrededor de React hace 7 años. Y en esto dice que la premisa fundamental de React es que las interfaces de usuario son simplemente una producción de datos en una forma diferente de datos. La misma entrada siempre produce la misma salida. Una función pura. Entonces, lo que eran las funciones de renderizado y nuestros componentes de clase en ese entonces ahora son componentes de función. Pero la regla sigue siendo la misma. Estas funciones, la función de renderizado y nuestras funciones de componente deben ser puras. No deben leer valores del mundo exterior. Por ejemplo, no deben usar math.random y no deben modificar el mundo exterior. Por lo tanto, agregar algunos event listeners, obtener algunos datos del servidor, porque React quiere tomar la decisión de cuándo ocurre el renderizado y qué parte de nuestra aplicación se renderiza. Nosotros, como desarrolladores, solo debemos vivir por encima de este nivel de abstracción para no interferir con todo lo que está por debajo de esta capa de abstracción.

Esto nos lleva a un par de malentendidos sobre este proceso de renderizado que simplemente asumimos que eran ciertos pero que nunca son realmente ciertos y no son ciertos hoy en día con las características concurrentes. El primer malentendido es que la fase de reconciliación es atómica. Entonces, el proceso de renderizado de React, como quizás sepas, se divide en esas dos partes, la fase de reconciliación donde React llama a todas tus funciones o tus componentes, genera el JSX, compara el JSX con la versión anterior para luego generar esas unidades de trabajo que se realizarán más tarde. Y esta parte posterior es la fase de confirmación.

Entonces, cuando todo se ha reconciliado, React sabe qué se debe hacer para que la interfaz de usuario coincida con el estado actual del mundo. Luego se ejecuta la fase de confirmación y React actualiza la interfaz de usuario, sin importar si es el DOM, React Native o la terminal o cualquier otra cosa. En este primer malentendido que tenemos en mente, vemos la reconciliación como un proceso atómico. Cuando comienza el renderizado, se ejecuta hasta el final. Esto era cierto en versiones anteriores de React, pero nunca se garantizó. Nunca fue una regla de React, simplemente sucedía que era cierto debido a los detalles de implementación.

En ese entonces, React utilizaba el llamado reconciliador de pila. Teníamos esta pila donde la biblioteca de React recorría nuestra aplicación hasta niveles inferiores, llamaba a la función de la aplicación, llamaba a la función principal, etc. Y el problema con ese proceso era que simplemente no era interrumpible. No era posible interrumpir esta fase de reconciliación. Por eso hicieron esta importante reestructuración con React 16, donde cambiaron a la arquitectura Fiber. ¿Qué significa esto? React ya no tiene la pila de componentes, sino que es una simple lista por la que podemos iterar linealmente para realizar el trabajo requerido para cada componente.

Y lo genial ahora con las características concurrentes es que ahora la fase concurrente, todo lo que hace React, también se puede dividir, si queremos eso como usuarios. Eso significa que el bucle de eventos, mientras tanto, tiene un poco de espacio para manejar algunas entradas del usuario. Por ejemplo, el usuario desplazó la página o hizo clic en el botón o ingresó algunos valores en un formulario. El bucle de eventos ahora puede procesar esos cambios porque React ahora puede ser interrumpido. React verifica después de cada componente, ¿todavía tengo tiempo o hay algún trabajo por hacer desde el navegador? Y luego cede al navegador para que el navegador pueda manejar este trabajo.

Debido a que esto es un poco difícil de entender, hice una pequeña demostración para eso. Lo que tenemos aquí es una pequeña aplicación donde a la izquierda tenemos esos tres componentes y en la parte superior tenemos algunos controles para que podamos controlar lo que sucede dentro de nuestra aplicación. A la derecha tengo la consola abierta, donde puedes ver que todos los componentes registran en la consola cuando comienzan a renderizarse y cuando terminan de renderizarse. Borremos eso y ejecutemos un nuevo renderizado. El primer componente comienza a renderizarse, luego termina. Después de eso, comienza el segundo componente y luego directamente después de eso comienza el tercer componente. Como tal vez puedas ver, cada componente tarda aproximadamente 5 segundos en hacer su trabajo. Este es un retraso artificial para que podamos observar más de cerca lo que está sucediendo aquí. Pero por defecto, este proceso de renderizado sigue siendo atómico.

Cuando hago clic en el botón de volver a renderizar, cambia este valor de estado global. Simplemente sigo haciendo clic hasta que todo termine con el renderizado. Puedes ver que React renderizó nuestro componente con el estado inicial y solo después de este proceso de reconciliación manejó mis eventos e incrementó el estado global, que es simplemente una variable global dentro de mi aplicación. También puedes ver que el estado en nuestro componente, en la interfaz de usuario, todavía representa el estado desde el inicio del proceso.

Durante esta reconciliación, React toma una instantánea dentro de esos elementos JSX y luego, cuando termina, confirma esas instantáneas en el DOM. Entonces, sin importar cuál sea el valor actual, confirma la instantánea desde el momento en que se ejecutó la reconciliación.

Ahora cambiemos a la actualización de baja prioridad. Está utilizando react-use-start-transition, como quizás ya hayas visto en otras charlas, para programar una actualización de baja prioridad. Ahora hagamos clic en volver a renderizar de baja prioridad y luego en cambiar el estado global nuevamente. Como quizás hayas visto, después de que el primer componente termine de renderizarse, React lo cede al navegador y el navegador decide que ahora necesita manejar esos clics de eventos. Llama a mi función que simplemente registra en la consola y cambia el valor de la variable, luego vuelve al navegador al bucle de eventos y el bucle de eventos decide que ahora React vuelve a tomar el control y continúa con el renderizado.

Esto sucede entre cada componente durante el proceso de renderizado, pero como ya puedes ver entre el componente 2 y 3, el bucle de eventos decide nuevamente darle a React la opción de hacer algo y no al controlador de eventos. Entonces, es un poco no determinista lo que está haciendo el navegador en segundo plano. A veces, los registros de la consola también aparecerían entre estos dos o solo aquí. Pero como puedes ver en nuestro caso, entre el componente 1 y 2, ocurrió el cambio en la variable. El primer componente se renderizó con el estado 25, el segundo se renderizó con 28 y el tercero también se renderizó con 28. Entonces, ahora puedes ver que el proceso de reconciliación ya no es estrictamente atómico en una aplicación moderna de React porque no sabemos si alguien más arriba en el árbol está utilizando esas características concurrentes y nos presenta esas fases de reconciliación que se dividen en el tiempo.

Y como puedes ver, esto conduce a problemas. Nuestro primer componente muestra el 25 y el segundo y tercer componente muestran el 28. Ahora tenemos este desgarro en nuestra aplicación. Una parte de nuestra aplicación muestra una instantánea en un momento determinado y las otras partes de la aplicación muestran otra instantánea en un momento determinado. Esto, por supuesto, no es lo que queremos.

Entonces, eso significa que necesitamos hacer para evitar este desgarro desagradable dentro de nuestras aplicaciones. Necesitamos dejar de leer valores que podrían cambiar fuera del mundo de React. En nuestro caso, esto era una simple variable global y leímos el valor de la variable y lo cambiamos en algún controlador de eventos. Si eso fuera una constante, estaría totalmente bien porque una constante nunca puede cambiar y luego podemos usar esa constante durante el renderizado. Pero necesitamos dejar de leer valores que podrían cambiar fuera de React. Por ejemplo, una variable local o almacenamiento local porque cualquiera puede escribir en el almacenamiento local o el valor actual de una propiedad de referencia porque esas referencias se hacen explícitamente para que tengas objetos que puedas mutar y restablecer fuera del mundo de React sin que React sepa que algo ha cambiado. Entonces, React no sabe que necesita volver a renderizar, no sabe que necesita abortar este nuevo proceso de renderizado concurrente y mostrará un estado inconsistente en tus interfaces de usuario en los peores casos. Y esto también significa que estás escribiendo tu propio Redux y líneas de moda, por ejemplo, que debes tener mucho cuidado de cómo lo conectas a tus componentes porque si simplemente llamas a getState() durante el proceso de renderizado, es el mismo problema.

Exactamente lo mismo que leer alguna variable global que puede cambiar, de modo que también puedes encontrarte con esos problemas de desgarro. La mayoría de las veces agregarás otro escucha de eventos, por ejemplo, para los cambios en el almacenamiento o para cambios en algún almacenamiento local, por ejemplo. Entonces, todo funcionará eventualmente, pero puede haber ciertos períodos de tiempo en los que tu aplicación muestre este estado desgarrado.

Antes de entrar en cómo puedes resolver estos problemas, veamos primero el segundo concepto erróneo. Una renderización o una fase de reconciliación siempre conduce a exactamente una fase de commit. Por defecto, esto puede ser cierto. Tenemos este proceso de reconciliación que recorre todos nuestros componentes dentro de nuestra aplicación y luego, cuando esto se completa y reconocemos lo que se debe hacer, cambiará a la fase de commit y ejecutará el commit y actualizará el DOM para todos nuestros componentes. Incluso cuando estamos utilizando características concurrentes, aún tenemos la garantía de que la fase de commit es atómica. Incluso si tenemos divisiones de tiempo en la fase de reconciliación, tenemos la garantía de que el commit es atómico porque el equipo de React tomó la decisión de que no quieren mostrar datos inconsistentes. Entonces, dicen que cuando comenzamos a actualizar el DOM, hacemos todo lo que actualmente tenemos que hacer para actualizar cada lugar que lee el estado para que todo esté en un estado consistente.

Pero ahora, hay algunas situaciones en las que la correspondencia uno a uno entre la reconciliación y la fase de commit ya no es cierta. Cuando estás utilizando el modo estricto de React en desarrollo, por ejemplo, ya tienes este cambio en el que la fase de reconciliación se ejecutará dos veces y la fase de commit solo se ejecutará una vez. Esto ya te advierte en desarrollo cuando esas dos fases de reconciliación producen resultados diferentes. Porque, como dijimos antes, cuando la entrada es la misma, la salida siempre debería ser la misma. Entonces, el modo estricto te ayuda a detectar cuando estás utilizando valores externos que podrían cambiar fuera de React. Por ejemplo, cuando estás utilizando math.random, React detectará que las diferentes fases de reconciliación producen resultados diferentes y te advertirá. Pero ahora, con esas características concurrentes, tenemos esas divisiones entre los pasos de reconciliación. Entre cada uno de esos pasos, algo podría suceder que podría hacer que la fase de commit sea obsoleta o cambiar el resultado de la fase de commit porque algún estado cambió nuevamente.

Podemos ver eso en nuestra aplicación de demostración nuevamente. Primero ocultemos nuestros bloques y marquemos la casilla Mostrar Commits, y limpiemos la consola. Ahora, mostremos nuestros bloques con una actualización de alta prioridad y luego, directamente después de eso, los ocultamos nuevamente. Después de eso, hago clic en Ocultar Bloques. Tenemos que esperar a que todos nuestros componentes se rendericen, uno, dos, tres, cinco segundos cada uno. Luego podemos ver que después de ese proceso, cuando se completa el renderizado, obtenemos esos commits para cada componente y directamente después de eso obtenemos esos desmontajes. Por defecto, tienes esta garantía de que estás renderizando y cuando terminas con la reconciliación, tus efectos se llamarán en la fase de commit y se llamarán los desmontajes porque nuestros elementos se ocultan directamente nuevamente. Ahora intentemos lo mismo con una actualización de baja prioridad. Mostramos los bloques con una baja prioridad y directamente después de eso ocultamos los bloques. Lo que podemos ver es que React renderizó nuestro primer bloque, el primer componente. Después de eso, cedió al navegador. El navegador manejó nuestro evento.

El evento establece la variable 'show', el interruptor 'show' vuelve a falso y React sabe que está bien, este es el estado antiguo que todavía tengo disponible aquí en mi construcción de renderizado concurrente. Por lo tanto, podemos cancelar esta nueva actualización de baja prioridad y mantener todo como está. Ahora tenemos este estado en el que se renderizó un componente, se llamó a nuestra función, pero no se realizó ningún commit. Por lo tanto, no se llamaron efectos ni efectos de diseño. Solo la fase de renderizado. Y esto, por supuesto, puede llevar a problemas. Y significa que nosotros, como desarrolladores, debemos dejar de suscribirnos o mutar el mundo exterior dentro de nuestros componentes. Porque cada vez que mutamos algo del mundo exterior o agregamos un escucha de eventos, por ejemplo, en una suscripción, entonces dependemos del hecho de que el usuario se desinscriba para limpiar después de nosotros. Pero en aquellos casos en los que solo tienes esta fase de reconciliación que se cancela por completo, nunca tendrás una fase de limpieza. Porque una función pura no necesita limpieza. Simplemente no la vuelves a llamar. Así que tenemos que asegurarnos de que nuestro renderizado en sí mismo sea puro nuevamente.

La buena noticia es que esto ocurre muy raramente en el código de la aplicación que hemos visto ahí afuera. Pero esto ocurre con bastante frecuencia en las bibliotecas de gestión de estado. Algunas bibliotecas intentan determinar automáticamente qué variables estabas usando durante la fase de reconciliación y agregar esas variables como dependencias a este componente en algún contenedor global de gestión de estado. El componente se renderiza y reconoce que estás leyendo algunos valores y los registra como una dependencia. Esto podría verse algo así. Tenemos esta referencia para este escucha y cada vez que se ejecuta el componente, verificamos si ya hemos instanciado ese escucha y, si no, simplemente creamos una nueva función y la colocamos dentro del arreglo de escuchas de eventos en el objeto window. El objeto window es, por supuesto, un objeto global y agregamos una función, por lo que mutamos la lista de escuchas de eventos y agregamos una función en este objeto global. Podríamos hacer eso cuando estemos absolutamente seguros de que useEffectCleanup() limpiará la función del escucha nuevamente. Esto eliminará el mismo escucha de eventos que agregamos anteriormente. Pero como acabas de ver, ya no tenemos esta garantía o nunca tuvimos esta garantía de que después de cada proceso de renderizado definitivamente habrá una fase de confirmación, lo que significa que no debemos hacer esto en nuestras aplicaciones. Nuevamente, esto se aplica más a los mantenedores de bibliotecas y a los autores de bibliotecas, ya que en las aplicaciones normales de React rara vez se ven patrones como este. Ahora pasemos a las tres soluciones para estos problemas. La primera solución es simplemente hacer toda la comunicación con el mundo exterior dentro de UseFX. Sé que hay algunos miembros de la comunidad que podrían matarme por decir eso, pero UseFX está hecho para eso, por lo que puedes sincronizar el mundo de React con el mundo exterior en UseFX, puedes iniciar solicitudes de red, puedes iniciar suscripciones, puedes agregar valores del mundo exterior dentro de UseFX, totalmente bien. El principal problema con eso es, en el contexto de la gestión de estado, por ejemplo, en el primer proceso de renderizado, aún no tienes el valor listo. Solo cuando renderizas una vez, confirmas una vez, muestras el valor inicial, pero no lo tienes del almacenamiento. Solo dentro de UseFX estás haciendo esa conexión con la biblioteca de gestión de estado, obteniendo el valor, colocándolo en el estado y volviendo a renderizar. Eso significa que funciona bastante bien para cosas asíncronas, pero para cosas sincrónicas es bastante engorroso, porque siempre conduce a este doble renderizado. La segunda opción es simplemente elegir una biblioteca que se haya hecho para tu caso de uso. La mayoría de las bibliotecas modernas de gestión de estado ya están preparadas para el modo concurrente, porque el equipo ha estado trabajando muy de cerca con los mantenedores de bibliotecas populares. Algo como ReduxToolkit o ReactQuery ya están preparados, por lo que puedes usarlos sin preocuparte por esos problemas de desgarro con las características concurrentes. La tercera solución, cuando realmente quieres crear tu propia solución, es usar el gancho incorporado useSyncExternalStore. Esto se hizo específicamente para hacer una conexión para sincronizar el valor desde un almacenamiento externo con el mundo de React. Para hacer eso, primero definimos una función de suscripción. En nuestro caso, nos interesa el tamaño actual del objeto window, por lo que nos registramos en el evento de cambio de tamaño. Cada vez que se llama a resize, el navegador llama a la función de cambio de tamaño, se llama a alguna devolución de llamada desde dentro de nuestra función de suscripción. Simplemente devolvemos una función de limpieza que luego eliminará esta devolución de llamada nuevamente del objeto global. Ahora podemos tomar esta función de suscripción y pasarla como primer argumento a useSyncExternalStore. Así que simplemente le damos a React la decisión de cuándo queremos suscribirnos. Decimos, React, maneja la suscripción y cada vez que alguno de los eventos cambie, cada vez que algo cambie, llama a mi función de selector, que es el segundo argumento de useSyncExternalStore. Cada vez que se dispara el evento de cambio de tamaño, nuestra función extrae el innerWidth del objeto window y lo devuelve desde nuestro gancho. Eso significa que dentro de nuestro componente, podemos usar este ancho y usarlo directamente dentro del renderizado inicial y obtener actualizaciones de los renderizados en el futuro, sin tener problemas con el desgarro. Eso significa que podemos volver a confiar en la abstracción que React proporciona, porque React no quiere que nos preguntemos cuándo se llaman nuestras funciones. Solo quiere definir nuestras funciones de una manera pura, por lo que tenemos que definir funciones puras que no se comuniquen con el mundo exterior, solo a través de esos ganchos definidos. Y luego, como resultado, puedes estar seguro en un mundo concurrente. Gracias por escuchar.