Turning It up to Eleven

Bienvenidos a Turning It Up to 11 en React Advanced. Mi nombre es Brett Little, y estoy realmente emocionado de estar aquí hoy.

De nuevo, mi nombre es Brett. Vivo en Maine. Cultivo flores y trabajo en Shopify en el equipo de Hydrogen. Hydrogen es un framework sobre Remix donde añadimos todo tipo de opiniones específicas de comercio electrónico que te ayudan a comenzar a construir un sitio de comercio electrónico muy rápidamente en Remix.

Puedes seguirme en littlebrett en Twitter. Pero Turning It Up to 11, ¿qué quiero decir con Turning It Up to 11? Hay una película muy, muy antigua. Tal vez nunca hayas oído hablar de ella, pero aquí tenemos a estos dos viejos rockeros que están hablando sobre rockear en el escenario. Específicamente, hablan sobre cómo sus amplificadores llegan hasta 11, todos los números suben hasta 11. Pero uno de los chicos pregunta, bueno, ¿por qué subirlo hasta 11? ¿Por qué no simplemente hacer que 10 sea el número más alto y hacerlo más fuerte en lugar de tener este extra 11 en el dial? Lo cual es algo interesante. Es como este momento divertido de este tipo de juego con la escala de números. ¿Realmente importa? Bueno, siento que la comunidad de desarrollo web a veces es un poco así. Discutimos, hay todo tipo de drama sobre este framework versus aquel framework. Esto es mejor, eso es peor. Y todos se molestan mucho, y hay todo este tipo de drama. Pero estoy aquí para decir que tu aplicación no es lenta debido a tu framework. Usualmente tu aplicación es lenta por la forma en que estás cargando datos.

Entonces, cuando digo cargar datos, ¿a qué me refiero? Bueno, la mayoría de las aplicaciones muestran mucho en la página y obtener todos los datos para mostrar en la página lleva tiempo. Así que en este caso, tal vez sea una aplicación de comercio electrónico. Una aplicación de comercio electrónico podría tener toneladas de productos. Esos productos podrían tener reseñas. Podrían tener disponibilidad, imágenes de precios, y muchos de estos datos podrían provenir de diferentes servicios, a veces incluso servicios de terceros. Y tienes que juntar todo eso, ponerlo en la página para que puedas renderizar algo, y eso a veces lleva tiempo. Así que la obtención de datos en Remix específicamente. Hagamos un pequeño repaso. Si no estás familiarizado con Remix, Remix proporciona rutas, enrutamiento basado en archivos. Cada archivo para una ruta puede tener una función asíncrona exportada que es un cargador. Esa función asíncrona exportada que es un cargador se va a ejecutar para definir los datos para esta página. Así que dentro de aquí puedes hacer cualquier solicitud asíncrona a cualquier API, obtener algunos datos, devolverlos del cargador, y luego esa función de exportación por defecto, podemos extraer esos datos dentro y podemos renderizar algo.

Lo que sea que se renderice aquí es lo que va a aparecer dentro de la aplicación. Pero estamos llevándolo al 11. Eso es bastante simple. La mayoría de las aplicaciones son mucho más complicadas que eso. Veo en el equipo de Hydrogen cientos de diferentes aplicaciones que están construidas que hacen algunas cosas increíbles dentro de sus loaders.

Así que consideremos lo que podría ser un poco más avanzado, lo que podría estar sucediendo. Así que dentro de nuestro loader, tal vez vamos a cargar algunos productos, luego tal vez vamos a cargar algunas reseñas, luego tal vez podríamos cargar recomendaciones. Y después de eso, también podríamos cargar el usuario que ha iniciado sesión para mostrar algo sobre quién ha iniciado sesión. Eso es genial. Este código realmente se ve muy, muy bien. Es realmente simple. Es fácil de entender. Carga esto, luego esto, luego esto. Se ve increíble.

Pero en realidad, hay un problema serio con este código. Específicamente, se llama lo que es una secuencia. Una secuencia es donde tenemos que cargar una cosa, y no es hasta que eso termina de cargar, que podemos proceder a cargar la siguiente cosa. Así que esencialmente, no estamos haciendo nada en paralelo. Estamos cargando uno, luego el otro, luego el otro, luego el otro. Así que esto es cuatro veces más lento de lo que necesita ser. Y la forma más fácil de resolver esto es simplemente envolver todo en promise.all.

Si envuelves todo en promise.all, ahora hay un await en la parte superior, y cargamos todo en paralelo, así que ahora la secuencia es plana. No hay ninguna espera en nada, y una vez que todo está hecho, podemos renderizar la UI. Pero si soy franco, esto no es tan intuitivo como esto. Como todo este asunto de promise.all, es un poco desafortunado JavaScript, siento que, los primitivos que tenemos, esto simplemente no se ve tan bien para muchos desarrolladores, y muchos desarrolladores, siento que, preferirían ver algo como esto.

Y la clave aquí, sin embargo, es que si alguna vez tienes más de un await en una función async no solo en Remix, solo en cualquier función async en JavaScript, si tienes más de un await, tienes una secuencia. Tal vez esa secuencia sea necesaria. Tal vez lo sea Pero si tienes más de un await, algo se está procesando, estás esperando que termine, y luego algo más se va a procesar después de eso. Así que si alguna vez ves más de un await en una sola función async, tal vez deberías considerar mirarlo, hablar sobre si es necesario, ¿podría ser paralelizado? Pero de nuevo, estamos llevándolo al 11, puede ser, no siempre es tan complicado. No siempre es tan fácil simplemente paralelizar todo en la función.

Por ejemplo, ¿qué pasa cuando hay dependencias de datos? Entonces en este caso, necesitamos cargar los productos, y no es hasta después de tener los productos, que tal vez tengamos que llamar a una API totalmente diferente, tal vez sea una API de terceros que aloja las reseñas. Cargamos los productos y luego llamamos a esa API de reseñas diciendo, dame las reseñas. Así que no podemos hacerlo en paralelo. Primero tenemos que obtener una cosa, y luego tenemos que ir a obtener otras cosas. Es lo mismo tal vez con un usuario que ha iniciado sesión. Tal vez hay un servicio de recomendaciones de terceros del que obtenemos recomendaciones sobre quién es la persona que ha iniciado sesión. No podemos hacer eso en paralelo. Primero tenemos que obtener alguna información sobre el usuario que ha iniciado sesión, y luego vamos a este otro servicio para obtener más datos. Así que eso es algo a considerar. ¿Qué pasa cuando hay dependencias de datos?

Entonces, si hay dependencias de datos, lo más fácil que podemos hacer es simplemente dividir claramente el único promise.all en dos promise.alls. Cuando tienes dos promise.alls, es un poco más óptimo. Como, sí, tenemos esta dependencia de datos, pero todavía tenemos esta cascada. Hay un await, lo esperamos. Una vez que termina, entonces hay otro await que necesita suceder. Entonces, ¿podríamos mejorar esto? Bueno, una cosa que puedes preguntar es, ¿qué es estático y qué es dinámico? Cuando digo dinámico, me refiero a cada solicitud que llega al servidor potencialmente va a ser un usuario que ha iniciado sesión diferente, y hay diferente información del usuario que ha iniciado sesión que necesita bajar. Mientras que cada solicitud que llega al servidor probablemente va a enviar los mismos productos. Así que la solicitud de productos es relativamente estática.

La solicitud del usuario conectado va a ser dinámica y potencialmente diferente para cada solicitud que llega al cargador. Así que si consideramos eso, si algo es estático, potencialmente podría ser almacenado en caché. Así que Kent Dodds ha publicado este gran paquete en Epic Web llamado Cachified. Cachified te permite almacenar en caché subsolicitudes en el servidor. Así que porque sabemos que los productos son relativamente estáticos, podemos decir, almacénalos en caché por un período de tiempo realmente largo. Incluso podemos servir una versión obsoleta de ese caché, y luego revalidarla en segundo plano. Pero cuando está en caché, lo que eso significa es que la primera persona que carga esta página, va a ser relativamente lenta. La primera persona que la accede, no habrá productos que se hayan cargado previamente, así que tendrá que salir y buscar los productos, pero luego puede guardarlos en algún tipo de caché. Luego, la segunda persona que accede a esta página, va a acceder a esto, muy primero, cargar productos, ya los tendrá, por lo que puede resolver inmediatamente, y puede ser realmente, realmente rápido. Así que todavía tenemos la cascada aquí, pero estamos haciendo la cascada un poco más rápida porque estamos añadiendo algo de almacenamiento en caché. Tal vez también podamos almacenar en caché las reseñas porque pensamos, las reseñas no cambian tan a menudo. Realmente no nos importa si las reseñas están súper actualizadas. Añadamos almacenamiento en caché.

Pero todavía tenemos dos awaits. ¿Cómo reducimos esos dos awaits a uno? Porque, de nuevo, hay esta cascada. Esto no es tan eficiente como podría ser. Realmente queremos llevar esto al máximo. ¿Cómo hacemos eso?

Bueno, antes de responder a esa pregunta, tal vez si damos un paso atrás, miramos esta página que estamos renderizando. Tenemos este producto, tenemos esta descripción, tenemos las reseñas aquí arriba con estas estrellas. Tenemos estas recomendaciones abajo. Tal vez este botón de añadir al carrito se muestra y está habilitado cuando hay producto disponible. Si no hay nada disponible, estará deshabilitado. ¿Qué en esta página es absolutamente esencial para que el usuario lo vea? ¿Qué es lo principal que es absolutamente importante, y qué es secundario?

¿Qué realmente no importa? Yo argumentaría que para una página de producto, al menos. Podría ser diferente para tu aplicación, pero esto es algo que deberías preguntarte si estás usando Remix. ¿Qué es esencial en esta ruta? Para esta página de E-commerce, las únicas cosas esenciales en la página son realmente la imagen, tal vez el título, la descripción, el precio, tal vez incluso la disponibilidad del producto. Eso no es tan importante. Eso podría venir después. Recomendaciones, eso no es tan importante. Las reseñas con las estrellas en la parte superior, eso no es tan importante. Supongamos que una de esas solicitudes falla a un tercero para obtener las recomendaciones. Si falla por completo, ¿quieres que toda la página simplemente explote? ¿O todavía queremos renderizar la información del producto y permitir que la gente compre algo? Las recomendaciones son geniales, pero no son esenciales para la página. Si consideramos lo que es absolutamente esencial para la página, podemos hacer algunos ajustes y algunas optimizaciones en nuestro código.

Si miramos hacia atrás en nuestro código original que hemos optimizado, añadimos almacenamiento en caché, hicimos todas estas cosas geniales, podemos eliminar uno de estos awaits. Si en su lugar actualizamos este código para que solo esperemos el contenido principal de la página, y el contenido principal de la página es el producto, aún en caché, todo lo demás, ya no lo estamos esperando. Si el await está desactivado, si no hay await aquí, las reseñas no son realmente las reseñas, es solo una promesa. Tiene un .then en él, tiene un .cache en él. Lo mismo con loggedInUser. Podemos devolver estos dentro de defer. Solo tenemos un awake. También podemos tener dependencias de datos aquí dentro. LoggedInUser, como las recomendaciones, todavía depende de loggedInUser. Todavía podemos expresar esa dependencia de datos solo con .then.

Entonces todas estas promesas se devuelven con esta función defer al final. Remix serializará las promesas a través de la red. Eso esencialmente solo significa que el resultado de estas reseñas, de nuevo, no se espera, cuando sea que llegue, cuando sea que se cargue, Remix se encargará de eso, y enviará, cuando termine, todos esos datos al navegador.

Si miramos el código del navegador, usamos loader data, el mismo tipo de código que teníamos antes, pero recommendations es una promesa. Tiene un .then en ella. Podemos pasar esa promesa dentro de un suspense boundary, podemos esperarla, y cuando se resuelva en el servidor, ahora vamos a renderizar las recomendaciones. Mientras se resuelve, durante ese tiempo, podemos renderizar algún tipo de estado pendiente como un skeleton UI. Esto es realmente importante para construir este tipo de experiencia. Ahora podemos decir, solo renderiza lo que es principal al frente, todo lo demás está envuelto en esos suspense await boundaries, y eventualmente, cuando se resuelvan, todo aparece. Esto es realmente importante también para cosas que están por debajo del pliegue. Así que cuando digo por debajo del pliegue, me refiero a si vas a desplazarte hacia abajo, así que tal vez hay todo tipo de otro contenido que está debajo de esto. ¿Por qué hacer que nuestra función loader espere a que todo eso se cargue cuando el usuario ni siquiera lo ve? Así que solo pon cosas esperadas que sean primarias para la página.

Estamos reducidos a un await. Así que si miramos este código, pensemos en ello. ¿Hay algún otro pequeño ajuste que podríamos hacer para que este código sea un poco más óptimo? A primera vista, tal vez no. Quiero decir, hay un await, todo lo demás es una promesa, está diferido al navegador. Bueno, considera esto. ¿Por qué esperar para cargar el usuario conectado y las recomendaciones? No son bloqueantes, como que no hay un await en ellos, pero sucede después de la solicitud del producto. Si simplemente intercambiamos esos y ponemos el usuario conectado y las recomendaciones antes de la solicitud del producto, pueden inmediatamente iniciarse. Pueden comenzar a cargarse de inmediato. Nada está bloqueando. Los datos primarios que estamos esperando son los datos del producto, pero eventualmente todo se resolverá en el navegador. Así que esto es algo a considerar también dentro de tus loaders. En general, pon lo que sea que estés esperando hacia el final de tus funciones async. Si tienes algún tipo de operación async que va a producir una promesa que simplemente puede iniciarse, lánzala un poco antes. Si la lanzas antes, entonces el proceso comienza un poco más rápido, y así se cargarán más rápido. Una cosa a considerar cuando escribes código como este, sin embargo, es si alguno de estos falla, digamos que el usuario conectado falla, digamos que las recomendaciones fallan, quieres asegurarte de que como no son primarios para la página, no van a prevenir que este cliente API cargue el producto. Si estos fallan, no quieres prevenir que el contenido principal de la página se cargue. Así que algo a considerar.

Pero, ¿qué más podríamos hacer para optimizar la carga de datos en nuestra aplicación? ¿Hay algo más que podríamos hacer? Bueno, ¿y si también pudiéramos almacenar en caché datos en el cliente? Así que los client loaders han sido añadidos recientemente a Remix. Con un client loader, podemos hacer cosas realmente geniales. Así que el client loader, la forma en que funciona es que estoy en una página. Transiciono a otra página. Cuando transiciono a la siguiente página, un loader necesita obtener datos para ejecutarse y obtener datos para esa siguiente página. Sin embargo, el client loader se ejecuta antes, y se ejecuta solo en el navegador. Y con ese client loader, podemos decir, ¿quiero ejecutar el server loader o no quiero ejecutar el server loader? Obtienes una referencia a él. Puedes esperarlo o no esperarlo. Si no quieres esperarlo, tal vez no vas a cargar los datos del servidor porque ya tienes los datos. Esencialmente, esto te permite construir un middleware dentro de tu aplicación donde puedes decir, escribe datos en el almacenamiento local.

Así que ahora realmente podemos construir nuestra aplicación de manera óptima de tal forma que ni siquiera vamos a acceder a la red si ya tenemos datos. Hydrate simplemente significa que el client loader se ejecuta cada vez que la página se carga. Sin él, solo se ejecutará cuando transiciones de una página a otra. Pero podría escribir manualmente un montón de código que sería como escribir en local storage, escribir en index DB, leer de él, hacer todo ese tipo de cosas. Remix client cache es un paquete que hace todo eso por ti. Así que si simplemente añades esto a tu ruta con tu client loader, solo llama a esa función. Y ahora, en lugar de usar loader data, llamo a use cache loader data. Los datos se almacenarán automáticamente en caché para ti, y serán intercambiados y recuperados sin que te preocupes por nada. Es genial.

Así que ahora lo hemos llevado al 11. Hemos añadido almacenamiento en caché del lado del cliente. Hemos añadido almacenamiento en caché de subsolicitudes del lado del servidor. Ahora estamos aplazando algunos datos para que se carguen de manera diferida en el navegador, así que solo los datos primarios se muestran primero. Hemos hecho muchas cosas, pero aún hay más que podríamos hacer. ¿Qué pasa si no hay conexión a internet? ¿Qué pasa si tu aplicación, quieres que esté disponible sin conexión? Como para construir generalmente una PWA, una aplicación web progresiva, necesitas tener un service worker. Si alguna vez has escrito un service worker antes, se siente como, no sé, necesitas un doctorado para hacerlo todo bien. Sin embargo, hay un gran paquete llamado Remix PWA. Remix PWA hace que gestionar el ciclo de vida de un service worker sea realmente fácil. Al igual que en Remix, tienes entry.server.js y entry.client.js. Ahora hay entry.worker.js, y con entry.worker.js, podemos gestionar todas las cosas que podríamos querer hacer dentro de nuestra PWA. Podríamos querer almacenar en caché el documento base. Podríamos querer almacenar en caché recursos de JavaScript o recursos CSS o imágenes. Puedes hacer todo eso con grandes ejemplos en Remix PWA.

Para recapitular, cada vez que estoy construyendo una nueva aplicación, o a menudo me llaman y estoy revisando el código de alguien, o alguien nos envía un mensaje y dice, el rendimiento de esta aplicación es pésimo, ¿cómo podemos mejorarlo? Estas son las preguntas que me hago cuando miro algún código nuevo, o incluso estoy pensando en construir algún código nuevo. En primer lugar, y de hecho debería decir, esto es lo mismo sin importar qué framework estés usando, generalmente. Tienes que hacerte este tipo de preguntas. He aplicado esto a Remix, pero esto se aplicará realmente a cualquier cosa por ahí, Next.js, Vue, Svelte. Tienes que hacerte este tipo de preguntas. Primero, ¿hay un waterfall en la aplicación? Si hay un waterfall, paralelicemos eso. Hagamos que las solicitudes ocurran en paralelo.

Pero, ¿hay dependencias de datos? Si hay dependencias de datos, no puedes paralelizarlo. Se vuelve un poco más complicado. La siguiente pregunta que hago es, ¿qué es crítico para la página? ¿Qué necesita cargarse primero antes que cualquier otra cosa? ¿Y qué se puede aplazar? Una forma de pensar en esto es qué es absolutamente necesario para determinar si la página puede responder con un 200. Si los datos no pueden cargarse, entonces necesita un 500 o necesita un error 400. Eso significa que es crítico. Lo que determina los códigos de estado de la página, eso es lo más importante. Eso necesita cargarse primero.