Video Summary and Transcription
Las mejoras de React en rendimiento, como la introducción de useEffect, han pasado desapercibidas. useEffect simplifica la sincronización de la lógica y mejora el rendimiento al eliminar los cálculos de diseño forzados. La agrupación de actualizaciones optimiza la representación al combinar múltiples llamadas a set-state en una sola representación. React 18 introduce llamadas agrupadas a set-state para un rendimiento más rápido. React Suspense y la hidratación selectiva mejoran la experiencia del usuario y la depuración de problemas de rendimiento se hace mejor de manera práctica. También se discuten los componentes del servidor, las herramientas de depuración recomendadas y las opciones de framework.
1. React Performance and useEffect
Las mejoras de React en rendimiento a lo largo de los últimos diez años a menudo han pasado desapercibidas. Hoy quiero hablar de los cambios ocultos que han hecho que las aplicaciones de React sean más rápidas. Una de estas mejoras es la introducción de useEffect, un hook que simplifica la sincronización de la lógica. Con useEffect, los desarrolladores ya no necesitan usar métodos del ciclo de vida como componentDidMount, lo cual requería más código. Sin embargo, junto con la mejora en la usabilidad, también se produjo una mejora deliberada en el rendimiento, que explicaré usando un cuestionario.
Entonces, empecemos. El título original de esta charla era los últimos diez años de rendimiento de React, así que para empezar, estoy bastante curioso, gente, ¿quién aquí ya ha utilizado React 19? ¿Podrían levantar la mano? Oh, genial. ¿Quién aquí ha utilizado alguna vez React 18? Bien. ¿Qué tal React 17? ¿Y React 16? ¿Y la versión 0.13? ¿Y la versión 0.3? No les creo. Esa fue la primera versión de React. Bueno, tal vez algunas personas sí lo hicieron.
De todos modos, React ha estado presente durante diez años, o al menos durante diez años ha pasado por una gran cantidad de cambios. Algunos de ellos mejoraron la compatibilidad, otros apuntaron directamente a mejorar el rendimiento. Pero hoy quiero hablar de las mejoras que la mayoría de los desarrolladores no notaron, que yo no noté durante años, mejoras que React nos pasó por debajo de la nariz para hacer nuestras aplicaciones más rápidas. En otras palabras, quiero hablar de la mano invisible del rendimiento de React.
Para empezar, hablemos de useEffect. ¿Quién aquí utiliza useEffect? ¿Quién aquí ama useEffect? ¡Una mano! Bueno, sí, les voy a mostrar una razón por la cual useEffect es en realidad un hook bastante bueno. Entonces, useEffect es un hook que nos permite sincronizar cosas, ¿verdad? Podemos ejecutar cierta lógica cuando el componente se monta, o cuando cambian algunas props, o en cada cambio. Antes de que se introdujera useEffect, lo mismo se podía lograr con los métodos del ciclo de vida. Tendrías un componente de clase, un componente escrito como una clase, no como una función, y esa clase tendría un método render que devuelve el JSX y métodos como componentDidMount o componentDidUpdate que me permitirían sincronizar los cambios de propiedades de la misma manera que useEffect, pero con más líneas de código.
Ahora, cuando salió React 16.8, useEffect prácticamente reemplazó a componentDidMount porque era mucho más fácil de usar, y ese fue un gran cambio, pero junto con el gran cambio de usabilidad también vino un cambio de rendimiento mucho más oculto pero muy intencional del cual quiero hablarles. Y para hablar de ello, tengo un cuestionario. Así que tengo este componente de React. Cuando el componente se renderiza, establece el color de fondo del cuerpo del documento en rojo. Cuando el componente se monta, establece el color de fondo en azul. La pregunta es, ¿qué colores mostrará el navegador? Opción A, rojo y luego azul. Opción B, azul y luego rojo. Opción C, solo azul. Opción D, solo rojo. ¿Qué colores mostrará el navegador? ¿Quién piensa que es la opción A? Bien. ¿Quién piensa que es la opción B? Muy bien. ¿Quién piensa que es la opción C? Genial. ¿Quién piensa que es la opción D? Muy bien. La respuesta correcta aquí es la opción C, solo azul. Ahora, tengo este código.
2. Efecto de useEffect en la Representación del Navegador
Con useEffect, el navegador representa los colores rojo y luego azul, mientras que con companyDidMount solo representa azul. Esta diferencia de comportamiento es una decisión deliberada de rendimiento tomada durante el diseño de useEffect, que solucionó una clase de problemas de rendimiento. Para entender esta diferencia y los problemas que aborda, debemos comprender cómo los navegadores representan las actualizaciones y utilizan el almacenamiento en caché. Cuando se lee un valor que no está en caché, el navegador debe recalcular estilos y diseño, lo que resulta en un problema de rendimiento conocido como cálculo de diseño forzado. Este problema se encontraba comúnmente al montar componentes.
La misma pregunta. ¿Qué colores representará el navegador? ¿Quién piensa que es la opción A, rojo y luego azul? ¿Quién piensa que es la opción B, azul y luego rojo? ¿Quién piensa que es la opción C, solo azul? ¿Quién piensa que es la opción D, solo rojo? Muy bien. Bastantes personas. La respuesta correcta aquí es la opción A, rojo y luego azul. Entonces, con useEffect, la respuesta correcta es rojo y luego azul. Con companyDidMount, la respuesta correcta es solo azul. Esta diferencia es el resultado de una decisión de rendimiento muy intencional que impulsó el diseño de useEffect y también ayudó a solucionar una clase completa de problemas de rendimiento. Pero para entender esta diferencia, para entender los problemas que solucionó, debemos hacer un desvío sobre cómo los navegadores representan las cosas bajo el capó.
El proceso de representación del navegador es complejo. Solo necesitas saber dos cosas al respecto. Primero, cada vez que un navegador tiene que representar una actualización, como tal vez un temporizador activado, tal vez hice clic en algo, lo que sea, siempre pasa por cuatro etapas. Primero, ejecuta el JavaScript. Luego, si el JavaScript ha actualizado la página, el navegador recalcula los estilos y recalcula el diseño. Y luego, una vez que haya terminado, el navegador pinta los resultados en la pantalla. Esta es la primera cosa que necesitamos saber, siempre cuatro etapas en cualquier actualización. La segunda cosa es que los navegadores utilizan mucho el almacenamiento en caché. Entonces, cada vez que se actualiza el diseño, por ejemplo, el navegador lo almacena en caché y lo recuerda hasta la próxima vez que el diseño tenga que actualizarse nuevamente. Por ejemplo, si renderizas la aplicación por primera vez en esta actualización N menos uno, y el navegador calcula que el encabezado tiene una altura de 200 píxeles. El navegador lo recordará y lo mantendrá en memoria hasta que digas hacer clic en el encabezado, y se expande, y el encabezado se vuelve 500 píxeles, porque ha cambiado. Entonces, cuando tienes, por ejemplo, una referencia de botón en React, y algún JavaScript code intenta leer la altura del botón, el navegador no necesita hacerlo de inmediato. El navegador simplemente irá a la caché y leerá el valor desde allí cuando se haya guardado después de la última actualización.
Ahora, imagina qué sucede si el botón cuya altura estamos leyendo acaba de montarse. ¿Qué sucede si aún no está en la caché? Tómate un segundo para pensar cómo se comportaría el navegador en ese caso. Entonces, lo que sucedería es que el navegador se vería obligado a recalcular los estilos y recalcular el diseño de antemano. Cuando leo algo que no está en la caché, el navegador se ve obligado a recalcular los estilos y el diseño de antemano. Entonces, cuando eso sucede, el navegador congela el JavaScript, calcula los estilos, calcula el diseño y luego devuelve la altura al JavaScript. Este es un problema de performance que se produce debido a un cálculo de diseño forzado. Este era un problema bastante común con el montaje de componentes. Supongamos que tienes un componente que se ve así. Supongamos que es un componente de botón, representa un botón y luego verifica si el botón es más alto que 300 píxeles y, si es así, hace algo con el botón.
3. Batching and Performance Optimization
companyDidMount requiere que el navegador realice un cálculo de diseño forzado, lo que causa retrasos. En cambio, useEffect se ejecuta en el siguiente frame, permitiendo que el navegador calcule y almacene en caché el diseño antes de consultarlo. Esto elimina los cálculos forzados y mejora el rendimiento. La introducción de useEffect fue impulsada principalmente por una API más simple, pero resolvió inadvertidamente una clase de problemas de rendimiento. Las optimizaciones invisibles de React hacen que nuestras aplicaciones sean más rápidas sin que nos demos cuenta.
Se utiliza companyDidMount. En React, se ejecuta justo después de la representación dentro del mismo bloque de JavaScript. Por lo tanto, necesita leer desde el diseño, como en este caso, y este diseño no está en caché, lo cual es muy común porque React actualiza la página, ¿verdad? A menudo invalidan el diseño. ¿Qué sucedería es que el navegador tendría que realizar un cálculo de diseño forzado, lo que congelaría companyDidMount hasta que se complete. Este es un problema común, y es lo suficientemente común como para que incluso las DevTools se preocupen por ello. Si alguna vez has realizado grabaciones de rendimiento de este tipo, es posible que hayas visto estos resaltados violetas. Esto es el cálculo de diseño forzado. Esto es lo que sucede cuando se lee desde el diseño donde las cachés aún no están presentes.
Compara esto con el componente que utiliza useEffect. A diferencia de companyDidMount, useEffect se ejecuta no en el mismo frame, sino al comienzo del siguiente frame. Esto lo cambia todo. Ahora, si renderizo un botón, primero React ejecutaría el JavaScript, luego el navegador calcularía los estilos y el diseño, luego pintaría los resultados en la pantalla y, solo una vez que todo esto haya terminado, useEffect se ejecutaría e intentaría leer desde el diseño. Ahora, cuando useEffect lee desde el diseño, el diseño ya estará calculado y en caché porque se ha realizado como parte de la actualización anterior, se ha realizado justo aquí, por lo que no se producirá ningún cálculo de diseño forzado. Simplemente lees desde la caché. Si revisas las DevTools, ya no verás ningún cálculo forzado. Solo verás JavaScript, estilo, diseño, pintura y luego en el siguiente frame, un poco más de JavaScript.
Ahora, observa cómo ninguna de las razones por las que se introdujo useEffect tenía que ver con el rendimiento. Cuando React 16.8 salió, la razón para migrar a useEffect fue porque proporcionaba una API más simple y fácil de usar, pero cuando nos mudamos a esta nueva API, este problema, toda esta clase de problemas, básicamente desaparecieron. Este es un ejemplo de la mano invisible del rendimiento de React. Así es como React hizo que nuestras aplicaciones fueran más rápidas sin que nos diéramos cuenta. ¡Ups! ¡Spoilers! Hablemos de lo siguiente, el batching, y para eso, tengo otro cuestionario. Entonces, aquí está el botón. Este botón tiene un evento onClick. El onClick llama a este event listener make document public, y el manejador de eventos tiene cuatro llamadas a setState. setState uno, setState dos, luego algunas llamadas a la API, setState tres, setState cuatro. Pregunta. ¿Cuántas representaciones tendrá este componente? Opción A, tres. Opción B, cuatro en React 17, tres en React 18. Opción C, tres en React 17, dos en React 18. Opción D, cuatro en React 17, dos en React 18.
4. Update Batching
El batching de actualizaciones es una optimización temprana de rendimiento de React introducida en la versión 0.4. Experimentó cambios significativos y recibió la mejora general más importante en React 16. El batching permite combinar múltiples llamadas a set-state en una sola representación. En React 18, las llamadas a set-state uno y dos, y tres y cuatro se agrupan, lo que resulta en dos representaciones. En React 17, solo se agrupan las llamadas a set-state uno y dos. La implementación del batching en React ha evolucionado a lo largo de los años, comenzando con un proceso de actualización simple y luego introduciendo más complejidad.
Ninguna mano. ¿Quién piensa que es la opción B? Dos manos y media. ¿Quién piensa que es la opción C? Bastantes manos. ¿Quién piensa que es la opción D? La mayoría de las manos. Muy bien. La respuesta aquí es la opción C. Esto sucede gracias al batching de actualizaciones, que es una de las optimizaciones de rendimiento invisibles más antiguas de React. Se introdujo en la versión 0.4 en 2013. Ha cambiado bastante en los últimos diez años y recibió la mejora general más importante en React 16.
Para entender por qué exactamente es cuatro en React 17, ¡perdón, tres en React 17! Para entender por qué es tres en React 17, dos en React 18, hablemos de cómo funciona el batching. El batching ocurre cuando tienes varias llamadas a set-state pero solo resultan en una sola representación. React 18 tiene dos representaciones porque las llamadas a set-state uno y dos, y tres y cuatro se agrupan juntas. Pero en React 17, solo se agrupan las llamadas a set-state uno y dos. Tres y cuatro no lo están. Levanta la mano si sabes por qué. Veo una, una, una, dos manos. ¡Genial! Para todos los demás, hablemos de por qué. Para entender por qué, veamos cómo React implementa el batching.
Supongamos que yo era meta, o Facebook en ese entonces en 2013, y estaba implementando React desde cero. ¿Cuál sería la forma más sencilla de implementar una llamada a set-state? Sería algo así, ¿verdad? Cada vez que alguien llama a set-state, tomo ese estado y realizo la actualización de inmediato. Así es como funcionaba React en las primeras versiones antes de que se introdujera el batching (con nombres de funciones diferentes, por supuesto). React 0.4 introdujo el batching. Las versiones posteriores solucionaron algunos casos especiales. En las versiones recientes de React, hasta React 18, la función set-state se volvió un poco más complicada.
5. React Batching and Update Processing
En React 17, las actualizaciones de estado se encolan y se procesan en función de la bandera de actualizaciones por lotes. Cuando la bandera es verdadera, las actualizaciones se procesan en el escuchador de eventos. Esto resulta en que solo se agrupen las primeras dos llamadas a set state. En React 18, todas las actualizaciones se agrupan por defecto y la función de procesamiento de la cola de actualizaciones se ejecuta al final del marco actual. Esto asegura que la función de procesamiento de la cola de actualizaciones solo se llame una vez, incluso si se llama a set state varias veces.
Así es como se veía en React 17. Primero, en React 17, cada vez que llamaras a set state, React no procesaría la actualización de inmediato. En su lugar, colocaría la actualización en la cola. Segundo, después de encolar la actualización, React verificaría si está agrupando las actualizaciones en este momento. Si no lo está, si la variable de actualizaciones por lotes está establecida en falso, entonces set state procesará la actualización de inmediato. Pero si lo está, entonces no se realizará ningún procesamiento. Set state solo colocará la actualización en la cola y no hará nada más. Por cierto, las actualizaciones por lotes son simplemente una bandera global que varias partes de React pueden establecer en verdadero o falso. Si estás agrupando, si alguna parte de React ha establecido la bandera de actualizaciones por lotes en verdadero y set state no está procesando la actualización, no está llamando a process update queue, ¿dónde se procesará la actualización en su lugar? La respuesta es que la actualización se procesará en el lugar que establece esta bandera de actualizaciones por lotes en verdadero, específicamente, en el escuchador de eventos. Así es como funciona esto. Entonces, cuando tienes un botón con un evento de clic, y pasas un callback a ese evento de clic, y ese clic se dispara, sucede lo siguiente. Primero, React establece la bandera de actualizaciones por lotes en verdadero. Segundo, se ejecuta el callback. Si el callback realiza alguna llamada a set state, estas se colocan directamente en la cola y no se procesan porque la bandera de actualizaciones por lotes está en verdadero. Tercero, la bandera se restablece a falso y, cuarto, ahora que hemos terminado de manejar el clic, finalmente se procesan todas las actualizaciones programadas. Así es como funciona el agrupamiento en React 17, 16, 15, y por eso, cuando tienes este código en React 17, solo se agrupan las primeras dos llamadas a set state. Porque en el momento en que esperas tu callback original, este callback se completa y las actualizaciones por lotes vuelven a ser falsas. Ahora, ¿cómo soluciona React 18 este problema? ¿Cómo se agrupan las actualizaciones en React 18 después de una espera? El truco es el siguiente. Primero, en React 18, ya no existe la bandera global de actualizaciones por lotes. Todas las actualizaciones ahora se agrupan por defecto. El envoltorio del escuchador de eventos, ahora que no hay bandera, simplemente llama al callback directamente. Segundo, la función de procesamiento de la cola de actualizaciones aún se llama, pero de una manera muy específica. Cada vez que llamas a set state, React ejecuta promise resolve y luego process update queue. Lo que esto logra es que se ejecute la función de procesamiento de la cola de actualizaciones, pero no de inmediato, sino al final del marco actual. Finalmente, React se asegura de que solo llame a la función de procesamiento de la cola de actualizaciones una vez. Si llamas a set state más de una vez, la función de procesamiento de la cola de actualizaciones aún se programará solo una vez. Así es como funciona esto. Deberías recordar este gráfico de un poco antes. Así es como funciona. Tienes un marco.
6. Actualización por lotes en React 18
En React 18, las actualizaciones de estado tres y cuatro ahora se agrupan, lo que resulta en un rendimiento más rápido. Las actualizaciones se procesan juntas después de que JavaScript se completa, utilizando la actualización por lotes.
El marco comienza a ejecutarse al hacer clic, luego al hacer clic llama a set state tres veces. Cada llamada a set state se coloca en la cola y luego, bueno, solo la primera llamada programa la función de procesamiento de la cola de actualizaciones. Luego, al completarse el clic, y tal vez se ejecute algún otro JavaScript si hay algo más que ejecutar, y solo después de todo eso, solo después de que el clic y todo el otro JavaScript haya terminado, finalmente se ejecuta la función programada de procesamiento de la cola de actualizaciones y procesa las actualizaciones, todas las actualizaciones, toda la cola que se recopiló durante las llamadas a set state. Así es como en React 18, las actualizaciones de estado tres y cuatro ahora se agrupan. Llamas a set state tres, coloca la actualización en la cola y programa el procesamiento, pero no procesa nada de inmediato. Llamas a set state cuatro, coloca la actualización en la cola y nuevamente no, bueno, esta vez no programa ningún procesamiento porque ya se ha programado, y luego JavaScript se completa, y se activa el procesamiento de la cola de actualizaciones, y luego ambas actualizaciones se procesan juntas. Esto es la actualización por lotes, y esta es otra mano invisible de React que hace que nuestras aplicaciones sean más rápidas desde el principio.
React Suspense and Hydration
Hablemos de suspense en React. Durante la hidratación, si se hace clic en un botón, la página se congela. Sin embargo, cuando el encabezado está envuelto con suspense, el clic se ignora.
Muy bien. Hablemos de una cosa más, que es el suspense, ¿adivina qué? Tengo otro cuestionario.
Entonces, aquí tengo un poco de JSX. Es un componente de encabezado con algunos hijos. Hay un icono, un menú que está colapsado por defecto. No sé por qué este puntero láser es tan lento. Y un botón que abre el menú.
Ahora, imagina que esta es una aplicación renderizada en el servidor. Si es una aplicación renderizada en el servidor, habrá algunos momentos en los que la aplicación no funcionará como se espera, ¿verdad? Por ejemplo, si acabas de abrir la página y aún no se ha cargado ningún JavaScript, el paquete aún se está cargando, puedes hacer clic en el botón, pero el botón no hará nada, ¿verdad? Porque aún no hay JavaScript. Y si el JavaScript se ha cargado, pero la aplicación aún se está hidratando, bueno, esta es mi pregunta para ti.
¿Qué sucede si se hace clic en el botón durante la hidratación? Opción A, nada. El clic se ignora. Opción B, nada, se registra una advertencia. Opción C, el clic se recuerda y se reproduce una vez que se completa la hidratación. Opción D, la página se congela. ¿Quién piensa que es la opción A? Bastantes manos. ¿Quién piensa que es la opción B? Más manos. ¿Quién piensa que es la opción C? Aún más manos. ¿Quién piensa que es la opción D? Dos manos. La respuesta correcta es la D. La página se congela. La hidratación, por defecto, congela la página durante el tiempo que tarda en hidratar la aplicación. Si la aplicación tiene 10,000 componentes, por ejemplo, la página se mantendrá congelada hasta que React renderice los 10,000 componentes. Si haces clic en la página durante la hidratación, la página se congela.
Muy bien, otro cuestionario. Aquí está la misma aplicación, la misma pregunta, pero esta vez, el contenido del encabezado está envuelto con suspense. Misma pregunta. ¿Qué sucederá con la página ahora? Opción A, nada, el clic se ignora. ¿Quién piensa que es la opción A? Nadie. Una mano, dos manos.
React Suspense: Hidratación selectiva
Opción B: nada, se registra una advertencia. Opción C: el clic se recuerda y se reproduce una vez que se completa la hidratación. Opción D: la página se congela. Así es como funciona el suspense: envuelve partes de tu página con suspense para la obtención de datos e introduce la hidratación selectiva.
Opción B: nada, se registra una advertencia. ¿Quién piensa que es la opción B? Opción C: el clic se recuerda y se reproduce una vez que se completa la hidratación. ¿Quién piensa que es la opción C? Bastantes manos. Opción D: la página se congela. ¿Quién piensa que es la opción D? Dos manos. La respuesta sigue siendo la D. La página se congela nuevamente, pero esta vez, se congela durante un período de tiempo mucho más corto, solo para hidratar los elementos dentro del suspense.
Así es como funciona esto. El suspense en general es un componente que se utiliza para la obtención de data, o tal vez ya no si tuviera que creer en los últimos hilos de discusión enojados. La idea es que envuelvas algunas partes de tu página con suspense y luego, cuando estés obteniendo algo desde dentro de esta parte, el suspense renderizará el fallback. Sin embargo, eso es solo una parte de la idea detrás del suspense. Una parte mucho menos notable de la idea es que el suspense también introduce algo llamado hidratación selectiva.
La idea se describe en una discussion en el grupo de trabajo de React 18, y también lo explico en detalle en mi otra charla, pero la esencia es la siguiente. A medida que tu sitio o aplicación crece, cada vez más partes de él se envolverán con suspense para hacer la obtención de data, como por ejemplo, si eres el sitio web de Airbnb, tendrás la búsqueda envuelta con suspense, y tal vez también tendrás cada listado envuelto con suspense, y así sucesivamente.
Comportamiento de Rack y Hidratación Selectiva
Cuando la página se hidrata sin suspense, Rack congela toda la página. Pero con suspense, el comportamiento de Rack cambia para hidratar suspense por suspense. El uso de layout effect tiene el mismo comportamiento que componentDidMount y componentDidUpdate.
Lo que hace Rack sin suspense es que cuando la página se hidrata, Rack congela toda la página. Comienza a hidratar el logo, luego comienza a hidratar el encabezado, luego comienza a hidratar la búsqueda, y luego los listados, y así sucesivamente hasta que toda la página esté hidratada. Si haces clic en algo, tendrás que esperar hasta que se complete toda la hidratación.
Pero con suspense, el comportamiento de Rack cambia. Ahora Rack hidratará la aplicación suspense por suspense. Hidratará un suspense, lo hará interactivo, cambiará al siguiente suspense, también lo hidratará cambiará al siguiente suspense, también lo hidratará, y se supone que debería mostrar los suspenses aquí. ¡Lo siento! Este suspense, este suspense, lo entiendes. Si haces clic en alguno de los suspenses mientras la página se está hidratando, la página se congelará solo hasta que ese suspense termine de hidratarse, lo cual será mucho más corto. Esto es hidratación selectiva. No voy a entrar en cómo funciona internamente.
La Mano Invisible de React y la Hidratación Selectiva
React implementa mejoras de rendimiento invisibles. Ejemplos: useEffect, batching, suspense. Más ejemplos no cubiertos. React recibe críticas, pero aprecio esta mano invisible. Preguntas y respuestas: useLayoutEffect es igual a did mount did update. ¿Cuál es el costo de agregar suspenses? No hay desventajas significativas. Hidratación selectiva: Rack hidrata los límites de suspense de arriba a abajo, eventos como clic fuerzan la hidratación.
Eso es otro tema completamente. Pero este es otro ejemplo de cómo React implementa mejoras de rendimiento invisibles bajo nuestras narices sin que nadie se dé cuenta. Entonces, use effect, batching, suspense, todos esos son ejemplos de la mano invisible de React que hacen que nuestras aplicaciones sean más rápidas. Hay varios ejemplos más de los que quería hablar, algunos exitosos, otros no tanto. Lamentablemente, no caben en esta ocasión. Sé que React recibe muchas críticas, a veces merecidas, pero esta mano invisible es algo que realmente me gusta mucho.
¡Gracias! Pasemos a las preguntas y respuestas. Todavía puedes hacer preguntas con el código 0614. Estoy emocionado por ver qué preguntas hacen las personas. ¡La espera me está matando!
Muy bien. ¿Use layout effect tiene la misma situación que did mount did update? Sí. Use layout effect tiene el mismo comportamiento que did mount, did update y esta es la razón por la que React desaconseja su uso, porque si lo usas, corres el riesgo de reintroducir los mismos problemas de rendimiento que tenía did mount. Chicos, silencio en la parte de atrás, gracias. Gracias.
¿Cuál es el costo de agregar suspenses? ¿Qué pasa si agrego 100 en una página? Hice la misma pregunta. Le pregunté a Dan Abramov sobre esto, como, oye, ¿qué pasa, por qué no puedo envolver cada elemento de la página con suspense? ¿Hay alguna desventaja nueva en esto? La respuesta que recibí fue que básicamente no hay desventajas significativas. El único problema que tendrás es que si algo se suspende, realmente se suspende porque está obteniendo algo, entonces, verás el fallback renderizado. Si olvidas proporcionar un fallback en algún lugar, eso será, bueno, el elemento se mostrará y desaparecerá. Pero aparte de eso, no tengo conocimiento de grandes desventajas. Gracias.
Hay un par de preguntas sobre la hidratación selectiva. ¿Puedo elegir qué hidratar primero, como en el ejemplo de Airbnb, y solo ocurre al hacer clic, y puedes contarnos más al respecto? Buena pregunta. Entonces, primero, ¿puedes seleccionar qué hidratar primero? Hasta donde sé, no puedes. Según mi conocimiento, Rack simplemente hidrata todos los límites de suspense de arriba a abajo. Probablemente haya algo de obtención de datos o espera de datos del servidor involucrado, pero no conozco ninguna API que te permita decir, como, hidrata esto primero. Además, no solo el clic lo fuerza, lo que fuerza la hidratación son todos los eventos que Rack llama discretos, que básicamente son clics, entradas y creo que eso es todo. Cosas como movimientos del mouse o desplazamiento que no deberían forzar la hidratación. Gracias.
Pareces estar muy metido en los detalles del rendimiento de React. Alguien pregunta...
Depuración de rendimiento y características de React 19
No por elección. ¿Recomendarías revisar el código fuente de React? No. Se vuelve obsoleto rápidamente. Prefiero un enfoque práctico para depurar problemas de rendimiento. Me centro en las partes relevantes del código fuente. Ivan olvidó las características de rendimiento de React 19. Los componentes estáticos y los componentes del servidor son sus favoritos actuales.
No por elección. No por elección. ¿Recomendarías revisar el código fuente de React? No. Nunca lo he hecho. Probablemente... Bueno, conozco a algunas personas que lo han hecho. Han creado publicaciones de blog muy buenas, que he leído. Esta publicación de blog se vuelve obsoleta en varios meses. Esa es una razón por la que no lo hago. La segunda razón por la que no lo hago es que, al menos para mí, funciona de una manera más práctica. Cuando tengo algún problema de rendimiento que necesito depurar, intento averiguar qué hace que el problema de rendimiento sea lento y luego no leo todo el código fuente, no reviso todo el código fuente, sino que reviso la parte que tiene sentido en mi contexto y luego lo entiendo mucho mejor. Sí. Eso es... Mira, estás haciendo el trabajo duro por ellos, de verdad. ¿Qué? Estás haciendo todo el trabajo duro por ellos. Vamos, pregúntale. Bueno, antes era consultor, así que... Ahí lo tienes. Antes lo hacía, sí. Ya no. Ivan, ¿de qué característica de rendimiento de React 19 estás más emocionado? Oh, vaya. Espera, olvidé las características de rendimiento de React 19. No recuerdo las características de rendimiento de React 19. ¿Cuál es tu favorita actual? Todas las que están en la lista. Ah, cierto, lo siento. Espera. Los componentes estáticos se vuelven estables en React 19, ¿verdad? Entonces eso es. Luego están los componentes del servidor. De acuerdo. Sí.
Componentes del servidor, depuración y elección del framework
Mucho amor por los componentes del servidor. Ivan explica cómo el suspense afecta la hidratación. Herramientas recomendadas para depurar aplicaciones web de React: Chrome DevTools, React Profiler y Why Did You Render. Astro y Svelte se consideran frameworks eficientes. Ivan no puede responder cuándo usar muchas solicitudes con Suspense.
Lo encontré. Mucho amor por los componentes del servidor en esta sala, ¿verdad? ¡Componentes del servidor, yay! ¡Wow! Una persona. Wow, wow, wow, wow. Veamos. Muchas preguntas. ¿Puedo ver una muestra de manos, quién es esta persona súper interesada en los PDF? Encuéntrame después, hablaremos.
Ivan, ¿hacer clic en suspense lo coloca en la parte superior de la cola de hidratación y hace que esta se hidrate más rápido aunque, por ejemplo, estuviera programada para hidratarse más tarde? Entonces lo coloca en la parte superior de la cola de hidratación, hacer clic en suspense, pero no creo que lo haga hidratarse más rápido porque no hay realmente nada que hacer más rápido. Necesita renderizar todos los componentes dentro del límite de suspense. No hay realmente nada que puedas sacrificar. Bastante justo.
Djer pregunta, ¿qué herramienta recomendarías más para depurar aplicaciones web de React grandes, lentas y dinámicas? Entonces aplicaciones web de React. Bueno, hago esto todo el tiempo, y normalmente uso Chrome DevTools y React Profiler. Sí. Realmente no lo sé, pero también está Why Did You Render, que es una biblioteca, no una herramienta de desarrollo. También es muy útil. Perdón, se llama Why Did You Render? Why Did You Render, sí. Si lo buscas en Google, lo encontrarás de inmediato. ¿Hay algo más que use? No realmente. No, principalmente eso. Y en tu experiencia, ¿hay algún otro de los marcos de React que consideres más eficiente desde el principio? Ooh. Ooh. Bueno, ¿Astro? Acaban de dar una charla sobre Astro. Sí. Depende si es una aplicación o contenido, supongo. No he trabajado mucho con otros frameworks, pero cuando era consultor, mis clientes trabajaban con otros frameworks, y creo que vi las aplicaciones más rápidas con Astro y Svelte. Con Astro puedes usar React, con Svelte no puedes usar React. Pero eso es lo que vi. Esta es más una pregunta de consejo. ¿Cuándo debo hacer muchas solicitudes con Suspense en lugar de una grande con todos los datos y viceversa? Lo siento, ¿puedo? ¿Cuándo debo hacer muchas solicitudes con Suspense en lugar de una grande con todos los datos y viceversa? No soy la persona adecuada para responder eso. Lo siento.
Factores de rendimiento y recursos recomendados
Ivan analiza los factores que afectan el rendimiento de la aplicación y el uso de Suspense. Recomienda recursos como Twitter, perf.email y la aplicación anteriormente conocida como Twitter.
Puedo decirte si es lento, puedo decirte por qué es lento. Esto depende en su mayoría... No lo sé. Estructúralo como quieras. Sí, lo siento, no soy la persona adecuada.
Y relacionado con esto, ¿Suspense ralentizará nuestra aplicación? Depende, supongo. Probablemente lo haría más rápido. No cambiaría nada. Realmente no debería ralentizar nada. Al menos en términos numéricos. En cuanto a la experiencia de usuario, si se usa incorrectamente, tal vez tendrías un montón de spinners cargando en la página, y eso haría que la página se viera peor en términos de experiencia de usuario. Pero eso es una discusión más detallada. Sí, eso es correcto. Lo siento, depende. Puedes encontrar a Ivan en los stands de preguntas y respuestas más tarde si quieres profundizar realmente en eso depende.
Una última pregunta de mi parte porque se nos está acabando el tiempo. ¿Tienes algún recurso que recomiendes a las personas para aprender más sobre React rendimiento o aprender cómo usarlo mejor en sus aplicaciones, aprovechar al máximo? Un poco de autopromoción, está mi Twitter, o ex. Twitter. En IAMAkulov, mi apellido. También hay un boletín de rendimiento muy bueno llamado perf.email. No se trata específicamente de React, pero es la mejor recopilación de recursos de rendimiento, actualizaciones regulares de rendimiento que encontré. Específicamente de React, no lo sé, creo que aprendí la mayoría de las cosas de mi ex. No el ex, la persona, la aplicación. Siempre es confuso. La anteriormente conocida como Twitter, esa. La anteriormente conocida como Twitter, sí.
Y esto no es una pregunta, pero alguien dice excelente presentación de la charla, por cierto, gracias, y estoy de acuerdo. Muchas gracias por tu tiempo, Ivan. Por favor, aplaudamos de nuevo. Gracias por acompañarnos. Gracias. Gracias. Gracias.
Comments