Construyamos Suspense 🥁

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

A medida que el péndulo del desarrollo web se inclina de nuevo hacia el servidor, la transmisión se ha vuelto cada vez más popular. Específicamente, la transmisión fuera de orden a través de características como React Suspense, los poderes mágicos detrás de los Server Components.

Construyamos nuestra propia versión simplificada para explorar cómo funciona, qué problemas estamos tratando de resolver y cómo se ve este futuro del desarrollo web.

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

Julian Burr
Julian Burr
20 min
22 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Hola, mi nombre es Julian y estoy muy emocionado de hablar en React Summit este año. Hoy, hablaré sobre Suspense en el servidor y su importancia en los React server components. Los React server components nos permiten diferenciar entre componentes estáticos y dinámicos, mejorando el rendimiento y la experiencia del usuario. Suspense mejora el rendimiento al introducir la transmisión y la transmisión fuera de orden. Podemos implementar suspense en el servidor creando un objeto suspendido para almacenar los hijos suspendidos y reemplazando el estado de carga por el contenido real utilizando elementos personalizados. Se pueden usar múltiples límites de suspense para renderizar estados de carga individuales para diferentes secciones, mejorando la experiencia del usuario.
Available in English: Let's Build Suspense 🥁

1. Introducción a Suspense y Componentes del Servidor

Short description:

Hola, mi nombre es Julian y estoy muy emocionado de hablar en React Summit este año. Hoy, hablaré sobre Suspense en el servidor y su importancia en los componentes del servidor de React. Echemos un vistazo rápido a cómo llegamos a los componentes del servidor, la historia del renderizado web y los problemas que encontramos en el camino: tamaño del paquete de JavaScript, hidratación y tiempo de respuesta lento del servidor. Los componentes del servidor nos permiten diferenciar entre componentes estáticos y dinámicos, mejorando el rendimiento y la experiencia del usuario.

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.

2. Understanding Suspense and Server-Side Rendering

Short description:

Los componentes del servidor de React no abordan el tercer problema, que es donde entra en juego suspense. Construiremos nuestra propia versión simplificada de suspense en el servidor para entender su funcionamiento conceptual y la evolución del renderizado clásico del lado del servidor. Esto demostrará cómo suspense mejora el rendimiento al introducir streaming y streaming fuera de orden.

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.

3. Building NotFlix Movie Application

Short description:

Veamos algo de código para construir una aplicación de películas llamada NotFlix. Tenemos una página sencilla con una sección de título, miembros del reparto y películas similares. Los componentes obtienen datos asincrónicos, pero no controlamos cuánto tiempo lleva. Son componentes del servidor sin estado ni efectos, lo que permite una obtención de datos conveniente.

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.

4. Improving Server-Side Rendering with Streaming

Short description:

Comencemos con el renderizado clásico del lado del servidor. Recopilamos HTML ejecutando componentes del servidor como funciones y convirtiendo los resultados en cadenas. El tiempo de respuesta lento del navegador al navegar a nuevas páginas es una mala experiencia de usuario. Para mejorarlo, introducimos la transmisión usando el método write en Express. Ya no necesitamos recopilar HTML en memoria y podemos enviar la respuesta de manera incremental, cerrando la conexión cuando terminamos.

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.

5. Rendering Order and Implementing Loading State

Short description:

Las secciones están fuera de orden porque estamos manejando promesas en paralelo. Para renderizar elementos en el orden correcto, cambiamos a un bucle for secuencial en lugar de un promise all. Sin embargo, todavía estamos viendo principalmente una pantalla en blanco mientras se carga el contenido. Para mostrar un estado de carga, usamos suspense en el cliente y lo implementamos en el servidor. También necesitamos hacer un seguimiento de los hijos suspendidos.

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.

6. Implementing Suspense on the Server

Short description:

Para implementar suspense en el servidor, creamos un objeto suspendido para almacenar los hijos suspendidos. Después de renderizar la aplicación, verificamos si hay entradas en el objeto suspendido. Si las hay, recorremos las entradas, obtenemos su respuesta, las convertimos en cadenas, las concatenamos y eliminamos la entrada del objeto suspendido.

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.

7. Swapping Loading State for Content

Short description:

Para intercambiar el estado de carga por el contenido real, necesitamos identificar el fallback y envolverlo en un div con un atributo de datos suspenseID. Podemos darle al div un display de contents para evitar problemas de diseño. Luego envolvemos el contenido real en una template y usamos web components o custom elements para indicar al navegador qué fallback reemplazar con el contenido. Se requiere JavaScript para que esto funcione.

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.

8. Implementing Swapping of Loading State

Short description:

Para implementar el intercambio del estado de carga con el contenido real, definimos un elemento personalizado llamado suspense content. La función de callback connected se llama cuando el elemento se renderiza. Encontramos el hermano anterior, que es un elemento template, y usamos el atributo target ID para localizar el límite de suspense correspondiente en el DOM. Luego intercambiamos el contenido HTML, permitiendo que el estado de carga sea reemplazado por el contenido real. Se pueden usar múltiples límites de suspense para renderizar estados de carga individuales para diferentes secciones, mejorando la experiencia del usuario.

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.

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

Simplificando los Componentes del Servidor
React Advanced 2023React Advanced 2023
27 min
Simplificando los Componentes del Servidor
Top Content
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
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.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.