Turning It up to Eleven

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Más a menudo de lo que parece, el rendimiento comienza con cómo se cargan los datos en tu aplicación. ¿Qué datos tienen dependencias? ¿Qué datos son críticos para la página? ¿Qué datos son variables? ¿Estáticos? ¿Personalizados? ¿Disponibles sin conexión? En esta charla, usaremos Remix para explorar cómo diferentes estrategias de carga de datos pueden mejorar la experiencia de tu usuario.

This talk has been presented at React Advanced 2024, check out the latest edition of this React Conference.

Bret Little
Bret Little
21 min
28 Oct, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Bienvenido a Turning It Up to 11 en React Advanced. Hydrogen, un marco de comercio electrónico construido sobre Remix, se centra en la carga eficiente de datos. Cargar datos en paralelo usando promise.all es cuatro veces más rápido que cargar de manera secuencial. Divide promise.all en dos al manejar dependencias de datos. Almacenar en caché datos estáticos puede mejorar significativamente el tiempo de carga de la página. Optimiza las páginas de productos reduciendo awaits y priorizando el contenido esencial. Usa límites de suspense y UI de esqueleto para una carga de datos óptima. Coloca solicitudes no bloqueantes antes de la solicitud de datos principal para un mejor rendimiento. Remix client cache maneja el almacenamiento en caché automáticamente. Considera las dependencias de datos y prioriza el contenido crítico.
Available in English: Turning It up to Eleven

1. Introduction to Turning It Up to 11

Short description:

Bienvenidos a Turning It Up to 11 en React Advanced. Soy Brett Little, un desarrollador en Shopify, trabajando en el equipo de Hydrogen. Hydrogen es un framework de comercio electrónico construido sobre Remix. La comunidad de desarrollo web a menudo se centra en debates sobre frameworks, pero la velocidad de tu aplicación está determinada por cómo cargas los datos. La obtención de datos en Remix se realiza a través de enrutamiento basado en archivos, lo que te permite hacer solicitudes asíncronas a APIs y renderizar los datos.

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.

2. Advanced Loader Techniques

Short description:

La mayoría de las aplicaciones son más complicadas que simplemente renderizar lo que está dentro de la aplicación. Cargar datos de manera secuencial, uno tras otro, puede ser cuatro veces más lento que cargar todo en paralelo usando promise.all. Tener más de un await en una función async indica una secuencia y puede necesitar ser reconsiderada para paralelización.

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.

3. Handling Data Dependencies

Short description:

Cuando hay dependencias de datos, divide el promise.all en dos promise.alls. Considera qué es estático y qué es dinámico. La solicitud de productos es relativamente estática.

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.

4. Caching Dynamic Requests

Short description:

La solicitud del usuario conectado es dinámica y potencialmente diferente para cada solicitud. El paquete Cachified de Kent Dodds permite el almacenamiento en caché de subsolicitudes en el servidor. Al almacenar en caché datos estáticos como productos y reseñas, el tiempo de carga de la página puede mejorar significativamente.

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é.

5. Optimizing Product Page

Short description:

Necesitamos optimizar el código para reducir el número de awaits y centrarnos en lo que es esencial para que el usuario vea en la página del producto. El contenido principal, como la imagen del producto, el título, la descripción, el precio y la disponibilidad, es crucial. Otros elementos como las recomendaciones y las reseñas no son tan importantes. Al actualizar el código y eliminar awaits innecesarios, podemos mejorar el rendimiento y asegurar que se muestre la información esencial.

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.

6. Optimizing Data Loading

Short description:

Remix serializa promesas a través de la red y envía los datos al navegador. Podemos usar suspense boundaries y skeleton UI para renderizar el contenido principal primero y posponer la renderización del contenido secundario hasta que se resuelva. Esto es especialmente útil para el contenido por debajo del pliegue.

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.

7. Optimización de Carga de Datos - Parte 2

Short description:

Considera optimizar la carga de datos colocando solicitudes no bloqueantes antes de la solicitud de datos principal. Usa client loaders para almacenar en caché datos en el navegador y recuperarlos del almacenamiento local al transicionar entre páginas.

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.

8. Advanced Application Optimization

Short description:

Ahora podemos construir nuestra aplicación de manera óptima sin acceder a la red si ya tenemos datos. Remix client cache maneja el almacenamiento en caché automáticamente, ahorrándote de escribir código adicional. Al agregar Remix PWA, puedes hacer que tu aplicación esté disponible sin conexión y gestionar el ciclo de vida del service worker. Considera estas preguntas al revisar o construir código: ¿Hay un waterfall? Si es así, paraleliza las solicitudes.

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.

9. Data Dependencies and Critical Content

Short description:

Considera las dependencias de datos y prioriza el contenido crítico para cargar primero. Determina qué se puede aplazar. Concéntrate en cargar los datos necesarios para que la página responda correctamente.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Todo Más Allá de la Gestión de Estado en Tiendas con Pinia
Vue.js London Live 2021Vue.js London Live 2021
34 min
Todo Más Allá de la Gestión de Estado en Tiendas con Pinia
Top Content
State management is not limited to complex applications and transitioning to a store offers significant benefits. Pinia is a centralized state management solution compatible with Vue 2 and Vue 3, providing advanced devtools support and extensibility with plugins. The core API of Pinia is similar to Vuex, but with a less verbose version of stores and powerful plugins. Pinia allows for easy state inspection, error handling, and testing. It is recommended to create one file per store for better organization and Pinia offers a more efficient performance compared to V-rex.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
React Query: ¡Es hora de romper con tu "Estado Global"!
React Summit Remote Edition 2020React Summit Remote Edition 2020
30 min
React Query: ¡Es hora de romper con tu "Estado Global"!
Top Content
Global state management and the challenges of placing server state in global state are discussed. React Query is introduced as a solution for handling asynchronous server state. The Talk demonstrates the process of extracting logic into custom hooks and fixing issues with state and fetching logic. Optimistic updates with mutation are showcased, along with the benefits of using React Query for data fetching and mutations. The future of global state management is discussed, along with user feedback on React Query. The Talk concludes with an invitation to explore React Query for server state management.
Los Átomos de Jotai Son Simplemente Funciones
React Day Berlin 2022React Day Berlin 2022
22 min
Los Átomos de Jotai Son Simplemente Funciones
Top Content
State management in React is a highly discussed topic with many libraries and solutions. Jotai is a new library based on atoms, which represent pieces of state. Atoms in Jotai are used to define state without holding values and can be used for global, semi-global, or local states. Jotai atoms are reusable definitions that are independent from React and can be used without React in an experimental library called Jotajsx.
Anunciando Starbeam: Reactividad Universal
JSNation 2022JSNation 2022
27 min
Anunciando Starbeam: Reactividad Universal
Starbeam is a library for building reactive user interfaces with JavaScript, similar to Svelte, Vue, and Ember. It provides a data structure and query feature for filtering and sorting. The useStarBeam function ensures JSX reconciliation only occurs when reactive dependencies change. Starbeam tracks every read and write operation to update the component accordingly. It can be used with React and other frameworks, and offers debugging tools and locale integration.
Pensando en React Query
React Summit 2023React Summit 2023
22 min
Pensando en React Query
Top Content
React Query is not a data fetching library, but an Asian state manager. It helps keep data up to date and manage agent life cycles efficiently. React Query provides fine-grained subscriptions and allows for adjusting stale time to control data fetching behavior. Defining stale time and managing dependencies are important aspects of working with React Query. Using the URL as a state manager and Zustand for managing filters in React Query can be powerful.

Workshops on related topic

Repensando el Estado del Servidor con React Query
React Summit 2020React Summit 2020
96 min
Repensando el Estado del Servidor con React Query
Top Content
Featured Workshop
Tanner Linsley
Tanner Linsley
La distinción entre el estado del servidor y el estado del cliente en nuestras aplicaciones puede ser un concepto nuevo para algunos, pero es muy importante entenderlo cuando se entrega una experiencia de usuario de primera calidad. El estado del servidor viene con problemas únicos que a menudo se cuelan en nuestras aplicaciones sorpresa como:
- Compartir datos entre aplicaciones- Caché y Persistencia- Deduplicación de Solicitudes- Actualizaciones en segundo plano- Gestión de Datos "Obsoletos"- Paginación y Recuperación Incremental- Memoria y Recolección de Basura- Actualizaciones Optimistas
Los gestores tradicionales de "Estado Global" pretenden que estos desafíos no existen y esto finalmente resulta en que los desarrolladores construyan sus propios intentos sobre la marcha para mitigarlos.
En esta masterclass, construiremos una aplicación que expone estos problemas, nos permite entenderlos mejor, y finalmente los convierte de desafíos a características usando una biblioteca diseñada para gestionar el estado del servidor llamada React Query.
Al final de la masterclass, tendrás una mejor comprensión del estado del servidor, el estado del cliente, la sincronización de datos asíncronos (un bocado, lo sé), y React Query.
Gestión del estado en React con Context y Hooks
React Summit Remote Edition 2021React Summit Remote Edition 2021
71 min
Gestión del estado en React con Context y Hooks
Workshop
Roy Derks
Roy Derks
Mucho ha cambiado en el mundo de la gestión del estado en React en los últimos años. Donde Redux solía ser la principal biblioteca para esto, la introducción de las API de Contexto y Hooks de React ha revolucionado las cosas. Ya no necesitas bibliotecas externas para manejar tanto el estado del componente como el estado global en tus aplicaciones. En este masterclass aprenderás los diferentes enfoques para la gestión del estado en la era post-Redux de React, ¡todos basados en Hooks! Y como bonificación, exploraremos dos próximas bibliotecas de gestión del estado en el ecosistema de React.