Construyamos Suspense 🥁

Hola, mi nombre es Julian, y estoy muy desanimado por no poder estar en Londres en persona para React advanced, pero espero que aún tenga una sesión algo interesante para todos ustedes desde el otro lado del mundo. Así que vamos a sumergirnos en ello.

Quiero hablar sobre suspense y un descargo de responsabilidad al principio. Soy un gran fan de suspense desde que comenzaron a mostrar versiones de vista previa allá por 2016. Para aquellos de ustedes que no lo saben, suspense básicamente te permite renderizar límites dentro de tu aplicación, para renderizar una interfaz de usuario de reserva, generalmente algún tipo de estado de carga, mientras cualquier cosa debajo de ese límite en tu árbol de aplicaciones todavía está esperando que algo asincrónico se resuelva. Así que eso podría ser llamadas a una API de terceros, podría ser carga diferida de fragmentos de JavaScript, lo que sea. Y eso es bastante genial en el cliente. Pero creo que suspense en el servidor es igualmente impresionante. E incluso iría tan lejos como para decir que es el héroe no reconocido de los componentes de React, porque los componentes de servidor de React tal como los conocemos no serían realmente viables sin suspense. Y en la charla de hoy, espero poder mostrar por qué creo que es así, y con suerte desmitificar algunas cosas que están sucediendo bajo el capó.

Antes de entrar en eso, sin embargo, quiero tocar rápidamente cómo llegamos a los componentes de servidor en primer lugar, cómo suspense se relaciona con todo eso solo para que todos estén en la misma página. Ahora, si miramos la historia del renderizado web, y la evolución del renderizado web en los últimos 15 a 20 años, muchos de nosotros probablemente aún recordaremos los días en que estábamos escribiendo HTML simple, y luego pasamos al servidor y creamos dinámicamente ese HTML con lenguajes como PHP.

Y eso tenía un gran inconveniente, que es, si haces mucho trabajo en el servidor, por ejemplo, para obtener datos de diferentes fuentes, ese tiempo de respuesta inicial del servidor puede volverse realmente lento. Y eso es obviamente muy malo para la experiencia del usuario. Así que cuando comenzamos a introducir JavaScript en nuestras aplicaciones para hacerlas más dinámicas, también introdujimos conceptos como AJAX, que nos permitieron, después de que la primera carga de la página ya está hecha, volver al servidor y obtener más cosas dinámicamente bajo demanda.

Y eso es bastante genial, porque significa que podemos descargar mucho de ese trabajo pesado al cliente y tener un tiempo de respuesta del servidor rápido, renderizar algún tipo de estado de carga, y luego hacer más trabajo. Y eso es tan conveniente que comenzamos a hacerlo más y más, hasta que finalmente nos acercamos a lo que ahora llamamos aplicaciones de una sola página. Y es entonces cuando todos los frameworks que conocemos y amamos como React, como Vue, como Angular comienzan a volverse realmente populares. Para obtener lo mejor de ambos mundos, sin embargo, luego reintroducimos rápidamente los conceptos de renderizado del lado del servidor y generación del lado estático en esos frameworks. Así que eso esencialmente trajo tres problemas principales todavía con él. Uno fue el tamaño del paquete. Así que desde las aplicaciones de una sola página, los tamaños de los paquetes de JavaScript siguieron creciendo y creciendo y se convirtieron en un problema. Con él, el segundo problema es el problema de la hidratación. Así que incluso si renderizas del lado del servidor tu aplicación de React, todavía necesita enviar todo ese JavaScript al cliente, y necesita ejecutar todo el JavaScript para hidratar toda la aplicación solo en caso de que algunas partes de tu aplicación usen lógica del lado del cliente, como estado, como efectos, como escuchadores de eventos, ese tipo de cosas. Y la hidratación es lenta. Así que la hidratación realmente comenzó a convertirse en uno de los principales cuellos de botella de rendimiento en las aplicaciones web modernas. El tercer problema es que estamos de vuelta en el servidor ahora. Así que nuevamente, tenemos el problema donde si el servidor hace mucho trabajo, y ese trabajo es lento, ese tiempo de respuesta inicial del servidor puede volverse realmente lento muy rápidamente.

Así que introducimos los componentes de servidor de React. Los componentes de servidor principalmente intentan hacer una cosa. Permite a los desarrolladores decirle al empaquetador qué componentes son estáticos y solo necesitan ser renderizados una vez, y cuáles son dinámicos y necesitan ser enviados al cliente y necesitan ser hidratados. Así que en una aplicación normal realista, esto puede realmente reducir masivamente la cantidad de JavaScript que necesitas enviar al cliente y la cantidad de hidratación que está ocurriendo. Así que eso es increíble, pero por sí solos, los componentes de servidor no hacen realmente nada sobre ese tercer problema. Así que ahí es donde entra suspense. Y para mostrar cómo suspense aborda ese problema, lo que vamos a hacer hoy es construir nuestra propia versión de suspense en el servidor desde cero. Y quiero ser muy claro aquí, esto no es cómo suspense está implementado en React. Esto es muy deliberadamente una versión muy simplificada, muy simplificada de ello. El punto principal aquí es solo mostrar cómo funciona conceptualmente, y también para mostrar cómo en las diferentes etapas mejora la experiencia. Así que comenzamos con lo que yo llamaría renderizado del lado del servidor clásico. Luego podemos ver cómo podemos mejorarlo introduciendo streaming, y luego cómo podemos mejorarlo aún más haciendo streaming fuera de orden, que es lo que suspense en el servidor nos permite hacer.

Muy bien. Suficiente charla. Vamos realmente a entrar en el código. Y para eso, vamos a pretender que estamos escribiendo una aplicación de películas, porque eso es lo que todos parecen estar haciendo hoy en día cuando están demostrando cosas. Puedes ver que se llama Notflix, porque definitivamente no es nada como Netflix. Soy realmente malo para nombrar cosas. Pero la página que estamos construyendo es bastante sencilla. Así que tenemos el logo en la parte superior, y tenemos una sección de título con el póster, y el título, y alguna información meta, año, géneros, y un resumen de la película. Luego tenemos una lista de miembros del reparto. Y en la parte inferior, tenemos otra lista de películas similares, porque definitivamente no queremos que nuestros usuarios dejen nuestra aplicación. Queremos que hagan maratones hasta el fin de los tiempos.

Bien. Si miramos el código, o más específicamente, si miramos los componentes que tenemos, aquí tenemos el componente de título, que es el póster y el resumen, y tenemos el componente de detalles, que es la lista de miembros del reparto. Y podemos ver que ambos componentes obtienen sus propios datos. Realmente no importa para el propósito de esta demostración de dónde provienen esos datos, si es de una API de terceros o internamente en nuestra base de datos. Todo lo que importa es que es asíncrono. Está haciendo algún trabajo que lleva tiempo. La otra cosa que podemos ver es que estos componentes son esencialmente componentes de servidor. Nuevamente, porque para el propósito de esta demostración, solo nos importa realmente el lado del servidor. Y lo que eso significa es que no pueden tener ningún estado, no pueden tener ningún efecto, pero pueden ser funciones asíncronas, de lo cual nos aprovechamos cargando los datos dentro.

Así que esto es importante. Ahora, comencemos con lo que llamo la forma clásica de renderizado del lado del servidor. Así que si miramos el código del servidor, vemos que es una configuración de express bastante estándar. Y en nuestra ruta, lo que hacemos es renderizar nuestra aplicación. Y luego comenzamos a recoger el HTML que eventualmente queremos devolver. Y para la aplicación en sí, simplemente iteramos a través de todos los hijos. Para todos los hijos, asumimos que pueden ser componentes de servidor. Así que los ejecutamos, pero esperamos, tomamos la respuesta, y luego la renderizamos a HTML. Luego concatenamos todo eso.

Y una vez que hemos recopilado todo el HTML, lo devolvemos al cliente. Y así es como se ve. Esto utiliza ese renderer, y podemos ver el problema que describí al principio simplemente haciendo clic en uno de los enlaces. Así que puedes ver que toma mucho tiempo. Y esto se debe a que el servidor tiene que hacer mucho trabajo asíncrono pero el navegador tiene que esperar a que el servidor termine todo ese trabajo para luego devolver el HTML antes de que el navegador pueda navegar a la nueva página. Así que eso es obviamente terrible desde la perspectiva de la experiencia del usuario.

Entonces, ¿cómo podemos mejorarlo? Como dije, introduzcamos streaming. Así que el streaming ha existido desde siempre. Básicamente, con la introducción de la World Wide Web y HTML. El streaming te permite iniciar la respuesta en el servidor, pero luego mantener la conexión abierta y simplemente seguir añadiendo a ese documento de respuesta a medida que las cosas están disponibles. Y frameworks como Express y otros frameworks de servidor hacen que sea realmente fácil para nosotros hacer eso. En Express, en el objeto de respuesta, expone un método write. Y eso hace exactamente eso. Escribe en el flujo de respuesta. Así que en lugar de recopilar todo el HTML, ahora realmente queremos escribirlo inmediatamente en el flujo. Ya no necesitamos eso. Así es. Y al final, ya no tenemos nada recopilado. Así que en lugar de enviar, simplemente terminamos la conexión. Eso le dice al navegador que hemos terminado y luego puede cerrarla.

Ahora, si actualizamos la página ahora, vemos que el logo se renderiza inmediatamente. Pero también puedes ver el problema. Puede que ya lo hayas notado antes y estés gritando a tu pantalla ahora mismo. La página se ve un poco desordenada, como si las secciones estuvieran todas fuera de orden. Y eso tiene sentido porque todavía estamos manejando todas las promesas de los componentes asíncronos en paralelo, lo cual no funciona porque en streaming, solo podemos añadir al final del documento. Así que en este caso, cualquier componente que resulte primero se renderiza primero, sobre lo cual no tenemos control. Así que para hacer que esto funcione, realmente necesitamos manejar las promesas en secuencia. Y sé que esto no es la forma más eficiente, pero para mantener las cosas simples para esta demo, simplemente convertiré esto en un bucle for secuencial en lugar de la promesa. Y si actualizamos la página ahora, nuevamente, el logo se renderiza inmediatamente y luego hace exactamente lo que queremos. Cada sección aparece a medida que está disponible.

Así que esto es mejor que con lo que empezamos, pero aún no es genial, ¿verdad? Todavía estamos mirando principalmente una pantalla en blanco si el logo no se renderizara en la parte superior, pero debajo de la sección del título, literalmente seguiríamos mirando una pantalla en blanco. Así que todavía no tenemos realmente un estado de carga ni nada. Así que no es genial.

Aquí es donde entra en juego suspense, ¿verdad? Suspense en el cliente, lo que haríamos es simplemente renderizar un límite, como dije al principio, y definir nuestro estado de carga que queremos renderizar en su lugar, ¿verdad? Así que intentemos construir eso en el servidor.

Primero, necesitamos construir ese componente porque ahora mismo no lo tenemos. Así que vamos a crear un nuevo componente, suspense. Y como dije, necesitamos una UI de reserva y los niños. Voy a ser perezoso con los tipos por cuestión de tiempo. Y por ahora, solo quiero devolver la reserva solo para empezar. Así que vamos a importarlo aquí.

Si volvemos y actualizamos la página, exactamente lo que esperábamos. Pero se renderiza inmediatamente. Así que eso es genial. Es un buen comienzo. Pero solo renderiza la reserva. Entonces, ¿cómo lidiamos ahora con los hijos realmente suspendidos?

Bueno, primero que nada, necesitamos mantener un seguimiento de ellos, ¿verdad? Siempre que suspendamos niños, necesitamos ponerlos en algún lugar. Así que vamos a introducir un objeto simple. Se llama suspendido. Y vamos a introducir la capacidad de dar a cada una de las instancias de suspense un identificador único. Nuevamente, todos se renderizan en el servidor. Así que todos solo se ejecutan una vez. Esto es perfectamente aceptable. Y luego podemos usar ese identificador único para realmente almacenar los niños suspendidos. Genial.

Y ahora en nuestro renderer, lo que podemos hacer es una vez que renderizamos toda la aplicación, podemos verificar eso. Así que si miramos en el objeto suspendido, podemos verificar si tiene alguna entrada. Y si lo tiene, lo que queremos hacer es básicamente recorrer las entradas del array. Y luego para cada una de esas entradas, esencialmente, lo que queremos hacer es lo mismo que hemos hecho antes en el renderer del lado del cliente, en el renderer clásico del servidor. Así que una cosa aquí, asegurándonos de que estamos tratando con un array porque los niños podrían ser un elemento o un array de elementos. Así que lo estoy forzando a un array, pero luego estoy haciendo lo mismo que hemos hecho al principio.

Estoy recopilando el contenido de todos ellos ejecutando las funciones asíncronas y luego simplemente concatenándolo al final y escribiéndolo en el stream. Una vez que hemos hecho eso, también podemos eliminar la entrada del objeto suspendido porque hemos terminado con eso. Y si ahora actualizamos la página, todavía vemos ese estado de carga inmediatamente. Pero luego, una vez que el contenido está disponible, comienza a aparecer, lo cual es genial. Estamos muy cerca de lo que realmente queremos aquí.

Lo único que todavía queremos es que en realidad no debería simplemente añadir al final del documento, ¿verdad? En su lugar, queremos que reemplace el estado de carga con su contenido respectivo una vez que el contenido esté allí. Así que ¿cómo podemos hacer eso? Acabo de describir la limitación del streaming, que solo puedes añadir al final del documento. ¿Cómo podemos reemplazar un elemento renderizado previamente? La respuesta corta es que no podemos. Y eso es, lo sé, realmente decepcionante. Pero como la mayoría de las cosas en el mundo hoy en día, la magia ocurre en JavaScript. Así que tenemos que añadir un poco de JavaScript para que esto funcione de la manera que queremos.

Y para eso, en realidad hay algunas cosas que necesitamos hacer. Primero, realmente necesitamos poder identificar el renderer de fallback, ¿verdad? Y si queremos reemplazarlo más tarde con el contenido, necesitamos tener un identificador. Así que envolvamos nuestro fallback en un diff y agreguemos algún tipo de identificador a él. Así que usamos un atributo de datos aquí. No queremos que este diff interfiera con tu diseño. Así que si tienes un diseño de grid o flexbox encima, hay un truco de CSS que puedes usar. Display contents básicamente le dice al navegador que ignore este diff para cualquier propósito de diseño, y simplemente seguirá mirando a los hijos para luego hacer su diseño de grid o flex. Así que eso es bastante genial. Así que tenemos el identificador.

Ahora aquí, hay dos cosas que queremos hacer. Una es que queremos envolver nuestro contenido una vez que esté disponible. Cuando lo renderizamos, queremos envolverlo en una etiqueta de template. Y la etiqueta de template básicamente nos permite aún agregarlo al documento, pero el navegador no lo renderizará, simplemente lo ignorará. Y luego queremos hacer el intercambio real. Y hay mil millones de maneras diferentes de cómo puedes hacer el intercambio del contenido. En esta demo, vamos a usar web components, o más específicamente, elementos personalizados. Así que pretendamos que tenemos un elemento personalizado llamado suspense content. Y tiene un target ID, que nos dice qué fallback queremos reemplazar. Y ahora, necesitamos el JavaScript para ello. Y como estoy un poco quedándome sin tiempo, voy a copiar y pegar esto de mis notas. Básicamente, lo que queremos hacer aquí es crear el elemento personalizado, definimos el elemento personalizado suspense content. Y los elementos personalizados nos permiten definir un callback conectado. Y ese callback conectado se llama cada vez que se renderiza esta etiqueta. Y aquí, básicamente solo estamos verificando el hermano anterior, que sabemos que es la etiqueta de template. Luego obtenemos el suspense ID de nuestro atributo target ID. Y luego buscamos el fallback de suspense correspondiente basado en el atributo de datos que acabamos de agregar. Y luego todo lo que hacemos es realmente intercambiar el inner HTML del límite de carga con lo que tenemos en la etiqueta de template. Y si ahora volvemos aquí, podemos ver que hace exactamente lo que queremos. Así que intercambia el estado de carga una vez que los datos reales están disponibles. Y no estamos limitados a un solo límite de sub-end.

Así que, como en el cliente, podemos incluir tantos límites como queramos. Así que envolvamos cada una de las secciones en su propio límite. Pero esto, si volvemos atrás, mejora aún más la experiencia del usuario, porque ahora cada una de las secciones puede realmente aparecer inmediatamente cuando estén listas. No tienen que esperar a que las tres secciones estén listas. Y podemos ver que desde una perspectiva de experiencia del usuario, eso es mil millones de veces mejor que con lo que empezamos.

Y también nos anima a usar más la plataforma. Sé que se ha convertido en una especie de meme, usa la plataforma, usa la plataforma. Pero hay una razón por la que los equipos alrededor de Remix, Astro, Quick, e incluso React siguen predicando que deberíamos usar la plataforma como Dios, también conocido como Tim Berners-Lee, lo intentó, ¿verdad?, porque no reinventes la rueda, usa lo que ya está ahí. Y un buen ejemplo aquí es la funcionalidad de retroceso y avance del navegador, por ejemplo. Porque el navegador almacena en caché toda la respuesta del servidor, incluyendo todo lo que transmitimos, si retrocedemos y avanzamos, no necesita volver al servidor y volver a buscar toda la información de la película, todo eso. Es instantáneo, porque todo eso ya está en esa respuesta del servidor en caché.

Así que creo que eso es bastante genial. Me estoy quedando sin tiempo aquí. Así que espero haber despertado un poco de curiosidad e interés en al menos algunos de ustedes. Así que si quieren profundizar en este tema, estos son algunos muy buenos puntos de partida para leer sobre suspense, suspense en el servidor, streaming fuera de orden, todo ese tipo de cosas. Si quieren echar un vistazo más de cerca al código que acabamos de escribir, este es el enlace al repositorio, enlace a las diapositivas, y también algunos enlaces a mis redes sociales. No soy muy activo allí, pero aquí estamos. Y eso es prácticamente todo de mi parte. Espero que realmente disfruten el resto de la conferencia. Todavía hay un par de charlas y sesiones de preguntas y respuestas por venir.