Construyamos Suspense 🥁

Hola, mi nombre es Julian y estoy muy emocionado de hablar en React Summit este año. Ahora, 20 minutos no es mucho tiempo, así que entremos directamente en el tema porque quiero hablar sobre Suspense. Soy un gran fan de Suspense, básicamente desde que comenzaron a mostrar las primeras versiones de él en 2016, así que hace bastante tiempo.

Pero para aquellos que no lo saben, Suspense básicamente te permite renderizar límites dentro de tu aplicación para luego renderizar interfaces de usuario de respaldo como estados de carga siempre que algo debajo de esos límites todavía esté esperando que se resuelvan promesas. Así que esos podrían ser llamadas a API, pero también podrían ser pequeños fragmentos de JavaScript perezosos o cualquier otra tarea asincrónica que estés haciendo en tu aplicación. Ahora, eso es bastante genial. Pero creo que Suspense en el servidor es aún más impresionante, e incluso diría que es el héroe no reconocido de los componentes del servidor de React porque sin él, los componentes del servidor tal como los conocemos no serían realmente viables. Y hoy, espero poder mostrar por qué creo que es así y también desmitificar algunas cosas que están sucediendo debajo del capó.

Ahora, antes de eso, quiero echar un vistazo rápido a cómo llegamos incluso a los componentes del servidor en primer lugar, cómo Suspense se integra en todo eso solo para que todos estemos en la misma página. Para hacer eso, tenemos que echar un vistazo rápido a la historia del renderizado web en los últimos 15 a 20 años. Y ahora, esto me hará sonar como una persona mayor, pero espero que muchos de nosotros todavía recordemos los días en que escribíamos HTML simple y luego eventualmente lo creábamos dinámicamente en el servidor con lenguajes como PHP. Ahora, eso vino con un inconveniente, especialmente si teníamos que hacer mucho trabajo en el servidor para obtener ese HTML, ese tiempo de respuesta inicial del servidor podría ser realmente lento. Y eso es obviamente 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.

Así que AJAX nos permite incluso después de que la respuesta inicial del servidor haya terminado, volver al servidor y hacer cosas. Así que eso significa que podemos descargar mucho de ese trabajo pesado, aún tener una respuesta rápida del servidor, respuesta inicial del servidor, y renderizar algún tipo de estado de carga mientras volvemos al servidor y obtenemos más datos o lo que sea que necesitemos hacer. ¿Verdad? Y eso fue tan conveniente que comenzamos a hacerlo más y más hasta que finalmente llegamos a lo que ahora conocemos como aplicaciones de una sola página. Y con ello vinieron todos los frameworks que conocemos y amamos como React, como Vue, como Angular. Y para obtener lo mejor de ambos mundos, esos frameworks muy rápidamente reintrodujeron los conceptos de renderizado del lado del servidor y generación de sitios estáticos. Pero llevamos algunos de los problemas que teníamos, a saber, el primero siendo el tamaño del paquete de JavaScript. Así que desde las aplicaciones de una sola página, los paquetes de JavaScript simplemente siguieron aumentando y aumentando. Y eso no es genial. Y también causó algo así como el segundo problema, que es la hidratación. Así que incluso si tu aplicación se renderiza del lado del servidor, React todavía necesita enviar todo el JavaScript al cliente y necesita ejecutar todo el JavaScript para luego hidratar toda tu aplicación, por si acaso algunas partes de ella necesitan lógica del lado del cliente, ya sea estado, efectos o escuchadores de eventos y ese tipo de cosas. Ahora, la hidratación puede ser realmente lenta. Así que, de hecho, eso comenzó a convertirse en uno de los cuellos de botella de rendimiento que estamos viendo en las aplicaciones web modernas. El tercer problema es que estamos de vuelta en el servidor ahora. Así que tenemos el problema original nuevamente, donde si estamos haciendo mucho trabajo en el servidor, ese tiempo de respuesta inicial puede volverse realmente lento. Así que introducimos componentes del servidor. El punto principal de los componentes del servidor es que los desarrolladores podamos decirle al empaquetador qué componentes en nuestra aplicación son estáticos, solo necesitan ejecutarse una vez y qué componentes son dinámicos y realmente necesitan ejecutarse en nuestro cliente y también necesitan ser hidratados.

Así que, de manera realista, en una aplicación normal, esto puede reducir masivamente el tamaño de tu paquete de JavaScript y con ello reducir masivamente la cantidad de hidratación que necesita ocurrir después del renderizado inicial. Pero por sí solos, los componentes del servidor de React no hacen nada respecto al tercer problema. Así que aquí es donde entra en juego suspense.

Para ver cómo suspense resuelve el problema, vamos a construir nuestra propia versión de suspense en el servidor desde cero. Ahora quiero ser muy claro aquí. Esta no es la forma en que suspense está implementado en React. Esta es intencionalmente una versión muy simplificada de ello. El punto principal que estoy tratando de hacer aquí es mostrar cómo funciona suspense conceptualmente y también pasar por la evolución de lo que llamaría renderizado clásico del lado del servidor y mostrar cómo podemos mejorarlo introduciendo algo como streaming y luego mejorarlo aún más introduciendo lo que se llama streaming fuera de orden, que es lo que suspense nos permite hacer.

Bien, suficiente charla. Vamos a ver algo de código. Y para eso, vamos a pretender que estamos construyendo una aplicación de películas porque aparentemente eso es lo que todos parecen estar haciendo estos días, al menos para las demostraciones. Y se llama NotFlix porque definitivamente no es como Netflix y soy realmente malo para nombrar cosas.

Pero podemos ver que la página que estamos tratando de construir es bastante sencilla. Así que tenemos nuestro logo en la parte superior. Luego tenemos una sección de título con un póster y el título de la película y alguna información meta como año, géneros y un resumen de la película. Luego tenemos una lista desplazable de los miembros del reparto. Y en la parte inferior, tenemos otra lista de películas similares porque definitivamente no queremos que el usuario deje nuestra aplicación, ¿verdad? Genial.

Si miramos el código para eso, o más específicamente, si miramos los componentes, podemos ver algunas cosas. Así que, por un lado, este es el componente de título, que renderiza el póster y el resumen y demás. Y este es un componente de detalles, que renderiza los clientes. Y en ambos, podemos ver la obtención de datos allí. Así que, para el propósito de esta charla, realmente no importa de dónde provienen esos datos, ya sea de una API de terceros o internamente, podría ser nuestra propia base de datos. Lo que importa es que es asincrónico. Así que tomará algún tiempo para que los datos estén allí. Y no estamos en pleno control sobre cuánto tiempo lleva eso.

La otra cosa que podemos ver es que son básicamente componentes del servidor. Así que, de nuevo, para el propósito de esta charla, solo nos importa realmente lo que está sucediendo en el servidor. Y lo que esto significa es que no pueden tener nada como estado o efectos, pero pueden ser funciones asincrónicas. Y para eso, significa que podemos hacer la obtención de datos como lo hacemos aquí, justo dentro del componente, lo cual es conveniente.

Ahora, comencemos con lo que llamo renderizado clásico del lado del servidor. Y veamos cómo podría verse el código del servidor para eso. Vemos que tenemos una configuración de express muy básica o estándar, y luego en nuestra ruta, estamos renderizando nuestra aplicación. Y luego comenzamos a recopilar HTML. Y básicamente para la aplicación en sí, simplemente estamos pasando por todos los componentes que renderizamos, y asumimos que cada uno de esos podría ser un componente del servidor. Así que los ejecutamos como funciones, y esperamos sus resultados. Y los convertimos en cadenas. Y luego al final, simplemente concatenamos todas las cadenas.

Y una vez que hemos recopilado todo el HTML, lo devolvemos al servidor, al cliente. Y cómo se ve eso, ya lo hemos visto. Básicamente usa ese render. ¿Verdad? Así que hace lo que queremos que haga. Pero también podemos ver el problema que estaba describiendo al principio. Si hacemos clic en uno de los enlaces aquí abajo, toma mucho tiempo para que el navegador realmente nos lleve allí. Porque el navegador tiene que esperar la respuesta del servidor, antes de que realmente pueda navegar a la nueva página. Y esto es obviamente una muy mala experiencia de usuario.

Entonces, ¿cómo podemos mejorar eso? Lo primero que podemos hacer, y ya lo insinué, es introducir la transmisión. Así que la transmisión ha existido desde siempre. Básicamente, desde la introducción de la World Wide Web y HTML. Y lo que hace, nos permite comenzar a escribir una respuesta, y luego mantener la conexión abierta, y seguir agregando a ese documento de respuesta, cada vez que algo se vuelve disponible. ¿Verdad? Y frameworks como Express y otros frameworks de servidor hacen eso realmente fácil. Así que en Express, en el objeto de respuesta, tenemos un método write que hace exactamente eso. Escribe en el flujo de respuesta. Así que usemos eso en todos los lugares donde estábamos recopilando HTML en memoria antes. Así que ya no lo necesitamos. Y úsalo aquí. Y luego tampoco tenemos nada al final que necesitemos enviar, porque ya hemos enviado todo. Y en su lugar, simplemente le decimos al navegador, mediante la función response end, que la conexión puede cerrarse. Ya hemos terminado. Y si actualizamos la página, vemos que hace lo que queremos.

Renderiza inmediatamente ese logo. Pero también puedes ver que hay un problema, y es posible que ya lo hayas notado antes, y estés gritando a tu pantalla ahora mismo. Nuestras secciones están todas desordenadas, están fuera de orden. Y tiene sentido. Todavía estamos manejando todas las promesas en nuestros componentes en paralelo en esta función promise all. Así que eso realmente no funciona porque en el flujo, como dije, solo podemos agregar al final del documento.

Así que para renderizar los elementos en el orden correcto, tenemos que manejarlos en secuencia. Y sé que esta no es la forma más eficiente de hacerlo. Pero quiero mantener las cosas simples para el propósito de esta demostración. Así que simplemente convertiré esto en un bucle for secuencial en lugar de un promise all. Y si actualizamos la página ahora, vemos que nuevamente, renderiza el logo inmediatamente. Y luego renderiza cada una de las secciones una vez que están disponibles. Ahora, esto es mucho mejor que con lo que empezamos pero aún no es genial, porque todavía estamos viendo principalmente una pantalla en blanco. Así que incluso si imaginas que el logo no estaba en la parte superior, sino que se renderizaba por alguna razón debajo de la sección del título, literalmente solo miraríamos una pantalla negra en blanco mientras el contenido se carga.

Así que eso aún no es genial. Entonces, ¿cómo podemos mostrar un estado de carga al usuario mientras se carga el contenido? Ahora en el cliente, podríamos simplemente hacer suspense aquí, como renderizar suspense boundary, y renderizar fallback aquí. Así que ese fallback aquí, como dije al principio, podría ser algún tipo de estado de carga. Luego envolvemos eso alrededor de todos nuestros componentes asíncronos y ese estado de carga se renderizará mientras ocurre el contenido asíncrono. Ahora implementemos eso en el servidor. Primero, necesitamos ese componente.

Y eso exporta la función suspense. Como dije, tiene fallback y children. Voy a ser perezoso con los tipos solo por cuestión de tiempo. Pero por ahora, simplemente devolvamos fallback, solo para comenzar. Y luego usa ese componente aquí. Y si actualizamos la página, hace exactamente lo que queremos. Renderiza inmediatamente el logo y el fallback. Así que ahora necesitamos hacer un seguimiento de todos esos hijos suspendidos que no hemos renderizado inmediatamente, pero que queremos manejar en segundo plano. ¿Verdad? Así que para eso, necesitamos una forma de hacer un seguimiento de ellos. Así que creemos un objeto simple que llamamos suspended.

Así que vamos a crear un objeto simple que llamamos suspended. Y luego necesitamos la capacidad de que cada instancia de suspense tenga un ID único. Así que sabemos, nuevamente, que solo estamos tratando con ellos en el servidor, por lo que podemos hacer esto fácilmente para asegurarnos de que cada instancia tenga un identificador único. Y luego podemos usar ese identificador para almacenar los hijos que suspendimos.

Y ahora, después de renderizar toda nuestra aplicación, podemos simplemente verificar, ¿tenemos alguna entrada en ese objeto suspendido? Así que si solo miramos la longitud de eso, sabemos, si alguno de ellos está allí, básicamente lo que queremos hacer es muy similar a lo que hemos hecho en el clásico renderizado del lado del servidor antes. ¿Verdad?

Así que queremos mirar todas las entradas del objeto suspendido. Luego nos aseguramos de que realmente estamos tratando con un array de elementos de React. Pero una vez que tenemos un array de elementos de React, simplemente los recorremos nuevamente, obtenemos su respuesta, los convertimos en cadenas, concatenamos todas esas cadenas al final, y luego eliminamos esa entrada del objeto suspendido porque ya la hemos manejado.

Si ejecutamos eso, todavía obtenemos el logar y el estado de carga, pero una vez que el contenido está listo, también aparece. Así que esto es genial. Como ahora estamos realmente cerca de lo que queremos, pero no del todo.

Así que el último paso que necesitamos es de alguna manera intercambiar el estado de carga por el contenido real una vez que esté disponible. Entonces, ¿cómo podemos hacer eso? ¿Cómo sorteamos la restricción que describí antes? Estamos trabajando con un stream. El stream solo nos permite añadir al final del documento. ¿Cómo reemplazamos realmente un elemento renderizado previamente con un nuevo elemento? Entonces, la respuesta corta es que no podemos.

Sé que es un fastidio, pero como la mayoría de las cosas en este mundo hoy en día, la verdadera magia ocurre en JavaScript. Así que necesitamos un poco de JavaScript para que esto funcione de la manera que queremos. Y básicamente hay algunas cosas que necesitamos asegurarnos de poder hacer. Una es que necesitamos identificar el fallback que queremos intercambiar porque podría haber múltiples fallbacks. Así que necesitamos poder decir cuál es el fallback correcto para el contenido que está listo.

Así que envolvamos el fallback en un div, le damos un atributo de datos que lo identifique. Llámalo suspenseID. Esa es solo la idea que ya tenemos. Y ahora un consejo de CSS al margen. No queremos que este div interfiera con el diseño de la página. Así que podemos darle un display de contents, que básicamente le dice a tu renderizador de CSS que ignore este div para cualquier propósito de diseño. Así que si eso está envuelto en un diseño de grid o un diseño de flex, este div será ignorado y CSS buscará en los hijos para cualquier propósito de diseño. Así que eso es bastante genial.

Y una vez que podamos identificarlo, lo que queremos hacer es envolver el contenido real en una template. Así que esto nos permitirá seguir añadiéndolo al documento, pero el navegador lo ignorará. No renderizará nada. Deja que la etiqueta template. Y la otra cosa que queremos hacer es ahora decir al navegador qué fallback debe intercambiar, ¿verdad? Así que el contenido está disponible. Queremos intercambiarlo en el lugar donde se renderizó ese fallback. Así que hay mil maneras de hacer eso para el propósito de esta demo, lo haremos con web components o más específicamente custom elements. Así que pretendamos que tenemos un custom element llamado suspense content, y que tiene un target ID. Esto nos permite decir al navegador, este es el ID con el que queremos intercambiarlo. Y ahora solo necesitamos escribir ese JavaScript que hace lo que hace.

Así que por cuestión de tiempo, porque se me está acabando, solo copiaré eso de mis notas, pero aún así lo revisaré como si realmente lo estuviéramos haciendo aquí. Así que todo lo que estamos haciendo es definir un elemento personalizado, como dije, llamándolo suspense content. Y esto básicamente nos permite usarlo como una etiqueta aquí. Y cada vez que la etiqueta se renderiza, se llamará a la función de callback connected. Y en esa función de callback connected, todo lo que estamos haciendo es buscar el hermano anterior, que sabemos que es un elemento template. Luego tomamos el ID de nuestros atributos del target ID. Usamos eso para en el DOM encontrar el límite de suspense, como nuestro fallback que renderizamos con el ID relacionado. Y todo lo que estamos haciendo es intercambiar el HTML entre sí. Genial. Si guardamos eso, refrescamos la página, esperemos que haga exactamente lo que queremos. Muestra el estado de carga, pero una vez que el contenido está ahí, ¡bang!, se intercambia con el estado de carga con el, con el contenido real. Así que el estado de carga se ha ido, el contenido real está ahí, y no estamos limitados a un solo límite de suspense tampoco. Así que al igual que en el cliente, lo que podemos hacer es envolver cada una de nuestras secciones en su propio límite de suspense para renderizar su propio estado de carga.