Renderizado: ¿Sincronizar o no sincronizar?

Rate this content
Bookmark

Vamos a profundizar en el renderizado de React y evaluar la implicación del Renderizado Concurrente y la agrupación automática en el código que anteriormente dependía de la naturaleza sincrónica de v17. ¿Siempre mejora las cosas? Con un estudio de caso del mundo real, evaluamos useSyncExternalStore y flushSync como herramientas para restaurar el renderizado sincrónico para evitar el “desgarro visual”. Trabajar a través de los compromisos de estos enfoques nos dará nuevas perspectivas sobre el renderizado de React y sugerencias sobre cómo podemos optimizar nuestras aplicaciones.

28 min
13 Nov, 2023

Comments

Sign in or register to post your comment.

AI Generated Video Summary

Esta charla discute el renderizado y la sincronización en React 18. Aborda problemas como filas parpadeantes y borrado al desplazarse. Se explora el uso de usync-externalstore para lecturas concurrentes y el posible mal uso de las APIs. Se discuten técnicas de depuración utilizando React Profiler y flush-sync. La charla también cubre consideraciones de rendimiento para diferentes máquinas y la importancia de probar y considerar soluciones alternativas.

1. Introducción a la Representación y Sincronización

Short description:

Hoy quiero hablarles sobre la representación y si vamos a sincronizar o no. Vamos a tener que intentar averiguar qué está pasando. El primer error que vamos a ver es que al hacer clic en la barra de desplazamiento se produce un flash. El segundo problema que tenemos es que cuando estás desplazándote, se borran por completo. Hemos actualizado a la versión 18 y cambiamos a CreateRoot, habilitando características de representación concurrente y agrupación automática. Vamos a ver el código que está causando las actualizaciones para la carretera, y no hay nada emocionante aquí. Pero creo que hay algunos sospechosos principales para este problema en la versión 18, la representación concurrente y la agrupación automática.

♪♪ Hoy quiero hablarles sobre la representación y si vamos a sincronizar o no. Hubo un error de tipeo gracioso cuando esto se compartió por primera vez en Twitter, donde en realidad era S-I-N-K, y yo pensaba, oh no, ¿es eso lo que están prediciendo para mi charla? Pero esperemos que no. Entonces, ¿sincronizar o no sincronizar? Vamos a profundizar en esto. Debería ser, con suerte, una pregunta fácil de responder.

¿Cuál de estas rejillas es mejor? Entonces, a la izquierda, tenemos Agigrid funcionando en la versión 17 de React, donde tienes este desplazamiento suave y agradable, puedes hacer clic en la barra de desplazamiento, y las filas simplemente aparecen en el lugar correcto. Pero luego actualizas a la versión 18. Entonces, esta no es una versión en vivo de Agigrid, esta es una versión antigua que tenía este problema. Haces clic en la barra de desplazamiento y las filas parpadean, o empiezas a desplazarte hacia arriba y hacia abajo y las filas se borran. Y es como, como puedes ver, esto no es lo que queremos que sea la experiencia del usuario. Entonces, vamos a tener que intentar averiguar qué está pasando.

Entonces, como saben, soy Steve, y trabajo en Agigrid, estoy en el equipo central de la rejilla. Y entonces, lo que estamos tratando de hacer en Agigrid es crear la mejor tabla de datos de JavaScript, ya sea en React o en cualquiera de los otros frameworks. Hay una versión gratuita así como la Enterprise, y si quieres saber más, ven a hablar con nosotros en el stand. Nos encantaría hablar contigo sobre todo ello. Pero basta de eso, vamos a tratar de aclarar lo que estamos tratando de arreglar y cómo ha cambiado React, cómo podemos tratar de averiguar cuáles son esos cambios, y luego cómo podemos arreglarlo. Entonces, el primer error que vamos a ver es que al hacer clic en la barra de desplazamiento se produce un flash. Veamos, ¿puedes ver eso? Sí. Y luego, el segundo problema que tenemos es que cuando estás desplazándote, se borran por completo. Bien, y entonces, esta es la única línea de código que es diferente entre esos dos ejemplos. Entonces, hemos actualizado a la versión 18, y luego cambiamos a CreateRoot. Entonces, cuando estás usando render, es el equivalente, básicamente, de la representación de la versión 17, pero ahora con la versión 18, cambia a CreateRoot, y luego vas a empezar a habilitar todas estas características de representación concurrente y agrupación automática. Y eso es lo que vamos a hacer. Vamos a ir a cazar errores. Entonces, lo primero que hay que hacer es, bueno, vamos a ver el código que está causando las actualizaciones para la carretera, y no hay nada emocionante aquí. Es solo estado. Entonces, cuando la carretera está cambiando, te desplazas y necesitas mirar nuevas carreteras. Vamos a actualizar qué carreteras se muestran. Entonces, no hay nada realmente, quiero decir, inusual allí, o complicado, o algo que debería estar saliendo mal. Pero creo que hay algunos sospechosos principales para este problema en la versión 18, representación concurrente y también agrupación automática. Y lo que vamos a hacer es, y ver si son estas dos características las que ahora están interactuando negativamente con la virtualización de filas de Aggrid.

2. Virtualización de Filas y Cambios en la Representación

Short description:

La virtualización de filas es una característica de rendimiento crítica para las cuadrículas de datos. Representar solo las filas visibles en el viewport evita sobrecargar el navegador. En la versión 18, hay un problema de parpadeo debido a los cambios en la representación, que ahora tiene instrucciones basadas en prioridades. Estos cambios, aunque habilitan características como useTransition, pueden tener efectos secundarios. Consulte los grupos de discusión de GitHub de React para obtener más detalles y contexto. También se recomienda la charla de Ivan para una mayor comprensión.

Entonces, supongo que, en primer lugar, ¿qué es la virtualización de filas? Esta es una característica de performance crítica para cualquier cuadrícula de data. Si quieres mostrar miles y miles de filas, no quieres tener que representar todo eso en HTML, porque vas a colapsar tu navegador y la experiencia va a ser realmente, supongo, lenta y difícil. Pero lo principal es, no quieres sobrecargar el navegador porque dibujar HTML es bastante costoso.

Entonces, lo que vamos a hacer es que solo representamos las filas que son realmente visibles en el viewport. Entonces, aquí vamos. Entonces, una forma de imaginar el desplazamiento es que desplazamos, el viewport cambia, y luego en este punto, si el navegador llega a repintar, va a repintar una cuadrícula vacía, porque las filas aún no se han actualizado. Y luego las filas se actualizan después de que nos hemos basado en la nueva posición del viewport. Entonces, creo que podemos imaginar que lo que está sucediendo es que las filas no se están actualizando lo suficientemente rápido, así como el viewport. Y entonces, otra forma en que podemos ver esto es en el perfil de DevTools.

Entonces, en la versión 17, tomaremos este benchmark de esta acción donde desplazamos y actualizamos el viewport. Y lo principal que hay que sacar de este gráfico es que hay una sola llamada a la función, y luego el navegador pinta. Entonces, lo que eso representa es que está desplazándose, cambiando donde está el viewport, y representando las filas de forma sincrónica, y luego el navegador está pintando. Entonces, no obtienes ningún tipo de parpadeo. Y si hacemos lo mismo ahora con la versión 18, debería ser bastante evidente de dónde viene este parpadeo, o el resultado de esa ruptura. Entonces, el desplazamiento ocurre, luego el navegador realmente tiene la oportunidad de repintar, por lo que ahora estamos obteniendo este conjunto vacío de filas antes de que las filas se representen. Entonces, estamos obteniendo dos pinturas en lugar de una. Ahí vamos. Y entonces, esto es algo de lo que necesitamos estar conscientes en la versión 18. Entonces, la representación ya no es un conjunto puramente secuencial de instrucciones. Pero hay prioridad en ello. Y muchas de las nuevas características en React, requieren que la representación sea interrumpible y soporte la entrega al navegador. Entonces, useTransition es un gran ejemplo de esto. Entonces, te permite actualizar el estado sin bloquear la UI. Pero estos cambios en la representación tienen algunos efectos secundarios y nos hemos topado con ellos aquí en esta situación. Entonces, no voy a profundizar en toda la concurrent rendering y todas esas cosas. Hay mucha buena información que puedes obtener en los grupos de discusión de GitHub de React. Hay tantas buenas pepitas de información allí en los comentarios y en las respuestas. Entonces, si no has mirado estas discusiones antes, definitivamente es un lugar que diría, echa un vistazo si quieres obtener algunos detalles más de bajo nivel o simplemente contexto detrás de algunos de estos cambios. Otra gran herramienta es de Ivan y él tiene otra charla más tarde hoy. Entonces, recomendaría escucharlo porque este definitivamente ayuda a explicar muchos de estos conceptos.

3. Uso de usync-externalstore para Lecturas Concurrentes

Short description:

Comenzaremos con usync-externalstore, una forma de soportar lecturas concurrentes forzando actualizaciones sincrónicas desde un almacén. El desgarro visual ocurre cuando React cede durante la representación, permitiendo que el almacén externo se actualice. En la versión 18, esto puede resultar en la visualización de colores en conflicto. Para usar useSync external store, necesitas un método de suscripción y un método de instantánea. El método de suscripción configura una devolución de llamada para notificar a React de las actualizaciones del almacén, mientras que el método de instantánea proporciona un estado inmutable del almacén para una representación consistente.

Bien, pero volviendo al problema, todavía tenemos que resolver este error porque no podemos lanzar este producto en el estado en que se encontraba. Entonces, en la documentation, hay dos características que contienen la palabra sync. Podríamos empezar por ahí.

Entonces, hay usync-externalstore y también flush-sync. Entonces, comenzaremos con usync-externalstore. Entonces, usync-externalstore, como sugiere el nombre, es una forma de soportar lecturas concurrentes forzando las actualizaciones desde un almacén a ser sincrónicas. Y todo esto tiene que ver con el desgarro visual, que es el término.

Entonces, la forma de visualizar esto o imaginarlo, esto es de uno de los grupos de discusión, es que digamos que el hijo sabe que está obteniendo su color a partir de un almacén externo. Entonces, el primero llega a representar y el almacén dice que deberías ser azul. Y luego React ahora cede, porque esto es parte de la nueva forma en que podemos tener una representación interrumpible, lo que ha dado al almacén externo la oportunidad de ejecutar una actualización y ahora decir que el color debería ser rojo. Entonces, en la versión 17, esto no era un problema porque React no estaba cediendo, por lo que el almacén no podría haberse actualizado hasta que React hubiera terminado toda su representación. Pero ahora, en la versión 18, porque React está cediendo durante su representación, el almacén externo está obteniendo la oportunidad de ejecutar una actualización, entonces, la representación continúa y ahora está recogiendo el color rojo. Entonces, el hecho de que hayamos visto azul y rojo mostrados al mismo tiempo se llama desgarro visual. Entonces, eso es algo que tal vez no está sucediendo en nuestra situación, o tal vez sí. Lo siento.

Entonces, ¿cómo usas useSync external store? Bueno, hay dos partes en ello. Necesitas un método de suscripción y también un método de instantánea. Entonces, la forma en que esto funciona es, necesitas, necesito apagar eso. Un segundo. Ahí vamos. No estoy seguro de cuál era. La suscripción es una forma de configurar una devolución de llamada para decir, voy a tomar esta función de React, así que eso es el estado cambiado, y voy a suscribirlo a mi almacén. Entonces, cuando las filas cambian, puedo llamar a esa función para decirle a React que algo se ha actualizado en mi almacén. Y entonces, cuando eso ha sucedido, React va a llamar a tu método de instantánea. Y el método de instantánea tiene que devolver un estado inmutable de tu almacén para que React pueda usar esa instantánea y completar su representación desde allí. Entonces, esta es la forma en que en lugar de que React siga volviendo al almacén durante la representación, simplemente devuelve la instantánea y luego la usa de manera consistente. Entonces, incluso si tu almacén se actualiza, React verá que se ha llamado a este método de cambio de estado, y volverá a obtener una nueva instantánea y reiniciará la representación en lugar de representar a mitad de camino y tener el desgarro. Así es como funciona este hook. Dices, usando almacén externo, le pasas el método de suscripción y también la instantánea. Y luego puedes usarlo como estado, como en tu controlador y simplemente mapearlos.

4. Renderización Sincrónica y Posible Mal Uso de la API

Short description:

El gran cambio es que la renderización se realiza ahora de manera sincrónica, lo que soluciona el primer error de filas parpadeantes al hacer clic en el viewport. Sin embargo, el segundo error de parpadeo continuo al desplazarse permanece. Potencialmente estamos utilizando la API incorrecta sin una tienda externa, pero continuemos por ahora.

Pero entonces el gran cambio es que esto se hace ahora de manera sincrónica. Entonces, ¿funciona? Bueno, sí, funciona. Soluciona nuestro primer error. Entonces, ahora puedes hacer clic y las filas no están parpadeando a medida que se cambió el viewport. Y podemos validar esto dentro del profiler. Entonces, una vez más, tenemos esta única función, donde estamos desplazando el viewport y actualizando las filas que se renderizan antes de que el navegador tenga la oportunidad de pintar, por lo que es por eso que ese parpadeo ahora se ha ido. Entonces, esto parece bastante bueno. Entonces, solucionamos el primer error, pero ¿qué pasa con el segundo? Al desplazarse, ¿vamos a obtener este parpadeo continuo de filas? Y también, vale la pena señalar aquí que realmente no tenemos una tienda externa. Entonces, potencialmente estamos utilizando la API incorrecta aquí, porque todo lo que estamos actualizando es el estado y no estamos teniendo nuestras filas, supongo, cambian como un conjunto durante la renderización. Entonces, creo que eso es algo que, ya sabes, solo deberías usar este hook en las situaciones correctas. Pero sigamos por ahora.

5. Depuración con React Profiler y flush-sync

Short description:

Al desplazarse con use sync external store, hay un ligero cambio en el comportamiento con la aparición de filas vacías. El procesamiento por lotes automatizado de React en la versión 18 reduce significativamente el número de renderizaciones en comparación con la versión 17. Sin embargo, este cambio disruptivo puede mitigarse con la opción de exclusión llamada flush-sync. Al usar flush-sync, puedes forzar a React a vaciar las actualizaciones dentro de un callback, asegurando las actualizaciones del DOM antes de realizar otras acciones. Ten cuidado, ya que un uso incorrecto puede afectar el rendimiento de la aplicación. Envolver las actualizaciones de estado en flush-sync puede renderizarlas de manera sincrónica y mejorar el rendimiento. Considera usar flush-sync en lugar de use-sync external store.

Entonces, esto es lo que sucede cuando empiezas a desplazarte con use sync external store. Es un comportamiento ligeramente diferente. No sé si puedes verlo bien, pero ahora hay filas vacías. Así que, anteriormente estaba completamente en blanco, pero ahora hay filas vacías.

Pero creo que la idea aquí es que algo todavía no está del todo bien. Entonces, aquí es donde podemos recurrir a otra herramienta y ahora para debug esto y mirar el profiler de React. Entonces, si comparamos los perfiles para el desplazamiento, en la versión 17 teníamos más de mil renderizaciones, esto es cuando haces mucho desplazamiento continuo. Pero en la versión 18, solo son 225. Entonces, algo está sucediendo que ha cambiado bastante radicalmente cómo React está renderizando esto ahora. Y eso nos señala de nuevo a nuestra otra característica sospechosa de procesamiento por lotes automatizado.

Entonces, esta es una mejora de performance fuera de la caja en React 18. Entonces, en la versión 17, las actualizaciones de estado dentro de un manejador de eventos se procesaban por lotes, pero las actualizaciones de estado en cualquier otro lugar no se agrupaban. Entonces, en la versión 17, este código dentro del set timeout resultaría en dos renderizaciones. Entonces, primero, actualizaría el recuento, React volvería a renderizar, establecería la bandera, volvería a renderizar. Pero en la versión 18 con procesamiento por lotes automatizado, ahora se agrupan juntos en la misma renderización y solo lo hará una vez. Entonces, esto suena como una gran victoria en performance. Y en la mayoría de las aplicaciones y situaciones, esto es exactamente lo que queremos. No queremos que React haga ciclos de renderización innecesarios cuando sabe dentro de este evento, esto es todo lo que ha cambiado. Pero este es un cambio disruptivo, y React, ellos lo notan, que es un cambio disruptivo. Y esperan que sea una mejora en performance. Pero también proporcionaron una opción de exclusión llamada flush-sync. Entonces ahora podemos ir a ver, bueno, ¿es esto realmente lo que necesitamos hacer para resolver nuestro problema?

Entonces, la idea detrás de flush-sync es que te permite forzar a React a vaciar las actualizaciones que haces dentro de un callback, y así puedes asegurarte de que el DOM se actualice antes de que, supongo, realices cualquier otra acción. Un caso de uso común para esto es el enfoque de entrada entre otras cosas. Pero entonces hay una trampa, por lo que podría perjudicar la performance de tu aplicación, y esto es porque estamos optando por salir de ese procesamiento por lotes automático. Entonces, lo que ejecutes dentro de este callback de flush-sync, vas a forzar al navegador a renderizar. Entonces, si lo usas de la manera incorrecta, podrías perjudicar la performance de tu aplicación.

Entonces, esta es una forma en que puede funcionar. Envuelves esas actualizaciones de estado en flush-sync, y así este está haciendo el contador y la bandera dentro de los flush-syncs, y va a forzar a React a renderizarlos ambos de manera sincrónica y tu lote de las dos renderizaciones. Entonces probemos esto ahora en nuestra situación. Entonces, en lugar de usar el use-sync external store, podemos usar flush-sync, que es mucho menos código.

6. Solucionando Actualizaciones Extras y Resolviendo Problemas de React 18

Short description:

No hay suscripción ni instantáneas, y simplemente envolvemos los controladores de fila en flush-sync. Una vez más, esto soluciona el primer error porque está forzando a renderizar de manera sincrónica, pero aún estamos obteniendo este mismo comportamiento, por lo que aún no hemos llegado al fondo del problema en términos de dónde se están agrupando todas estas actualizaciones extras. Así que ahora es cuando podemos volver al código y pensar, bueno, en realidad, no solo está diciendo qué filas deberían volver a renderizarse, también son las filas individuales donde podemos decir qué celdas se están renderizando. Así que dentro de un componente de fila, tienes muchas celdas diferentes, y eso es otra parte del estado. Así que cuando se crea una fila, luego obtiene las celdas que debería mostrar y eso es otro set state. Así que si también hacemos flush sync en ese momento, entonces le estamos diciendo a React, en realidad, quiero que renderices este conjunto de filas, pero para cada fila individual, asegúrate de renderizar todas esas celdas y vaciarlas. Así que una vez que hacemos eso, hacemos flush en las filas y las celdas, volvemos al tipo de rendimiento y experiencia de la versión 17, y hemos resuelto los problemas que se introdujeron con React 18, lo cual es genial.

No hay suscripción ni instantáneas, y simplemente envolvemos los controladores de fila en flush-sync. Una vez más, esto soluciona el primer error porque está forzando a renderizar de manera sincrónica, pero aún estamos obteniendo este mismo comportamiento, por lo que aún no hemos llegado al fondo del problema en términos de dónde se están agrupando todas estas actualizaciones extras, sí, ya que todavía solo está en el 225 y no en la versión 17. Así que ahora es cuando podemos volver al código y pensar, bueno, en realidad, no solo está diciendo qué filas deberían volver a renderizarse, también son las filas individuales donde podemos decir qué celdas se están renderizando. Así que dentro de un componente de fila, tienes muchas celdas diferentes, y eso es otra parte del estado. Así que cuando se crea una fila, luego obtiene las celdas que debería mostrar y eso es otro set state. Así que si también hacemos flush sync en ese momento, entonces le estamos diciendo a React, en realidad, quiero que renderices este conjunto de filas, pero para cada fila individual, asegúrate de renderizar todas esas celdas y vaciarlas. Así que una vez que hacemos eso, hacemos flush en las filas y las celdas, volvemos al tipo de rendimiento y experiencia de la versión 17, y hemos resuelto los problemas que se introdujeron con React 18, lo cual es genial.

7. Rendimiento de Renderizado en Diferentes Máquinas

Short description:

Flush Sync resulta en una mejor experiencia de usuario para máquinas más lentas al forzar a los navegadores a volver a renderizar una fila a la vez. Si el componente se está ejecutando en máquinas más rápidas, se puede utilizar el renderizado sincrónico para un mejor rendimiento. Sin embargo, es importante ser cauteloso y considerar el entorno específico donde se está ejecutando la aplicación.

Pero otra cosa, que es un efecto secundario de esto, es que realmente ayuda mucho en máquinas más lentas. Entonces, Flush Sync, resulta en una mejor user experience porque ahora estamos obligando a los navegadores a volver a renderizar una fila a la vez. Entonces, si nuestros usuarios están en una máquina subpotenciada, realmente no queremos que ellos vean lo que está sucediendo a la derecha donde desplazan y está completamente en blanco y se quedan preguntándose, ¿hay algún data llegando o no? Al menos a la izquierda, pueden ver, bueno, está tomando tiempo, pero los data están llegando. Entonces, quiero decir, esto es muy extremo, he hecho el renderizado. Solo gira durante un par de segundos antes de dejar que React continúe. Pero es una idea donde no siempre estamos en control de dónde se está ejecutando nuestro componente. No podemos asegurar que todos tengan una Mac realmente rápida, M2, laptop o algo así. Por lo tanto, es importante que como component library, trabajemos para asegurarnos de que el predeterminado se amplíe se ejecute en todos los diferentes lugares donde podría ser utilizado. ¿Y qué pasa con las máquinas más rápidas? Bueno, si sabes que Agigrid solo se va a utilizar en máquinas más rápidas, puedes sortear todo esto y decir, sí, simplemente voy a dejar que el renderizado sea sincrónico. Porque si tu máquina es lo suficientemente rápida para poder mantenerse al día con las actualizaciones de una manera que no la está bloqueando, entonces puedes obtener un rendimiento realmente agradable de esa manera. Pero tienes que tener cuidado de que sepas exactamente dónde se está ejecutando esta aplicación, si estás en control, así que si estás en una empresa interna y conoces las especificaciones de todo, eso podría ser adecuado para ti. Pero no es el predeterminado porque podría llevar a este bloqueo.

QnA

Conclusiones y Preguntas y Respuestas

Short description:

React 18 ofrece mejoras, pero verifica las suposiciones con tu aplicación. Inicialmente emocionados por el batching, pero causó parpadeo. useExternalStore no era la opción correcta. FlushSync solucionó el problema. Considera el rango de máquinas para el rendimiento. Para más información, consulta mi charla sobre patrones de rendimiento en React Advanced London. Visita el stand de Agigrid para más información.

Entonces, conclusiones. Así que React 18 ofrece muchas mejoras, pero necesitas verificar las suposiciones que se están haciendo contra tu propia aplicación. Entonces, para nosotros, al principio estábamos emocionados. Pensábamos, OK, batching, eso va a ser bueno. Eso va a mejorar el performance. No vamos a renderizar tanto. Pero luego, como puedes ver, llevó a estos efectos secundarios donde obtenemos este parpadeo, que definitivamente no es lo que queríamos. Así que vimos que podríamos usar useExternalStore, pero no era la opción correcta. Y FlushSync fue realmente la solución que estábamos buscando. Y luego, también es importante considerar la amplia gama de máquinas en las que se va a ejecutar tu aplicación o componente y degradar el performance o el renderizado de manera apropiada. Entonces, si quieres más información, di otra charla sobre patterns para performance hace tres semanas en React Advanced London. Y ese es otro lugar donde miramos, bueno, ¿cómo podemos evitar renders también haciendo manipulación directa de estilo? Entonces, si quieres más información sobre lo que estamos haciendo en Agigrid para asegurarnos de que el componente sea lo más rápido posible, ese es otro recurso que podrías encontrar interesante. Pero gracias por escuchar, y si quieres saber más sobre Agigrid, ven a vernos al stand. Y espero que no tengas preguntas demasiado difíciles para mí. Siguiente.

Actualización y Depuración de React 18

Short description:

A partir de la versión 18 de React, hay otros beneficios además del cambio de renderizado. La actualización depende del caso de uso y las necesidades de la aplicación. Resolver problemas y depurar la versión 18 de React puede llevar tiempo. Utiliza DevTools Profiler y React Profiler para obtener información. Compara la salida entre versiones y sé metódico al probar soluciones. Estos no son errores sino cambios que desbloquean nuevas características. Considera el contexto específico de la aplicación y el impacto en el rendimiento. La actualización puede requerir más trabajo, especialmente para desplazarse a través de grandes conjuntos de datos. Considera las limitaciones de las máquinas y las capacidades de renderizado de React.

--. --. --. --. --. --. La primera es, a partir de la versión 18 de React, ¿no es lo mismo que usar la versión 17 de React? ¿Hay algún beneficio en usar la versión 18 de React si usamos las mismas funciones? Sí, bueno, creo que hay otros beneficios en React 18 además de este cambio en el renderizado, y también te dará control, en otras partes de tu aplicación para tal vez usar características como use deferred value o use transition. Así que creo que no deberías bloquear la actualización pensando que no va a funcionar porque esto también depende mucho del caso de uso y de lo que está haciendo tu aplicación. Así que sí, no me abstendría de actualizar por esto. Así que la respuesta es actualizar. Sí. En resumen.

La siguiente pregunta es, ¿cuánto tiempo te llevó resolver estos problemas al actualizar y qué consejos generales o temas se pueden usar para depurar la versión 18 de React? Sí, esto me llevó, esto me llevó un tiempo. Y creo que ahí es donde también, fue la combinación de usar el Profiler de DevTools así como el Profiler de React para obtener información sobre, bueno, qué ha cambiado. Y definitivamente hay mucha comparación de, sabes, podrías ver la salida en la versión 17. ¿Por qué no estaba haciendo lo mismo en la versión 18? Y ejecutando en modo de desarrollo, también puedes ver algunos de los nombres de los métodos en el Profile, lo que puede darte un poco más de información sobre lo que está pasando. Y luego, sí, entonces es solo ser muy metódico con eso y probar cosas y registrar tus pasos a medida que avanzas, para que no estés solo probando cosas, cambiando muchas cosas al mismo tiempo. Porque creo que sí, definitivamente cambia una cosa a la vez, ve qué pasa, repite el proceso. Suena bien.

La siguiente es, estamos hablando de errores, pero estas son nuevas características de React. ¿Por qué estamos hablando de soluciones alternativas en lugar de abordar los problemas subyacentes del código? Así que no diría que esto es un error en React. Diría que esto es un cambio en el comportamiento, que desbloquea muchas nuevas características que React puede hacer y soportar. Así que hay un gran valor en estas características concurrentes. Creo que tal vez lo que tú, donde probablemente pueda dar más claridad, es que hay cosas específicas dentro de Agigrid para permitir este tipo de degradación del rendimiento en máquinas más lentas, que también está interactuando con React también.

Pruebas de Rendimiento y Throttling en Herramientas de Desarrollo

Short description:

Es importante probar el rendimiento para máquinas lentas para garantizar la eficiencia. El throttling en las herramientas de desarrollo es un buen primer paso, pero puede que no sea completamente preciso. Servicios como BrowserStack permiten realizar pruebas en dispositivos físicos de manera virtual. Puedes obtener más información en Twitter.

Por lo tanto, es importante ver en tu aplicación lo que realmente está sucediendo. Porque si vas por la ruta completamente síncrona con el renderizado, todo está bien, sabes, el batching funciona. Pero eso significa que hay más trabajo para tu cosa que hacer. Y desplazarse a través de muchas filas de data es una operación costosa. Las grids tienen muchos componentes en ellas. Por lo tanto, está empujando el límite de lo que React puede hacer basado en lo que las máquinas también pueden renderizar. Nos encanta una victoria en eficiencia, así que eso es bueno.

La siguiente es, ¿cómo pruebas el performance para máquinas lentas? Así que hay algunas formas diferentes. Hay throttling en tus herramientas de desarrollo. Tengo algunas reservas sobre si es completamente preciso. Pero luego hay otros servicios por ahí donde puedes tener una URL si la has desplegado en algún lugar y puedes iniciar sesión y ejecutar en dispositivos físicos virtualmente, así que esa es una forma bastante útil de obtener una sensación real de ello, porque no estoy seguro de que las DevTools de Chrome o las otras cuando estás haciendo ese throttling sean completamente precisas. Es un buen primer paso, pero si quieres estar 100% seguro, entonces podrías querer buscar tu viejo portátil o probarlo en las máquinas en las que se va a ejecutar. ¿Sabes cuáles son esos servicios? ¿Dónde deberíamos encontrarte en Twitter para una respuesta? Creo que es BrowserStack, ese es uno que he usado. Si no quieres registrarte en él, obtienes alrededor de un minuto creo en cada dispositivo y diferentes versiones, así que puedes ir probando las diferentes versiones y obtener una idea del performance. Suena bien.

Soluciones Alternativas y Pruebas

Short description:

Se probaron diferentes soluciones y rutas de depuración, incluyendo el almacenamiento externo Usync. Encontrar el equilibrio adecuado entre el renderizado síncrono y considerar los diversos entornos de usuario es crucial. Es importante probar el ciclo de vida completo del componente y tener en cuenta diferentes dispositivos, como iPads.

La siguiente pregunta, vamos a desplazarnos. ¿Se probaron otras soluciones además de las presentadas u otras rutas de depuración que tomaste? Sí, probé muchas cosas diferentes. Sí, el almacenamiento externo Usync casi nos llevó allí, pero también dependía de nosotros apagar las funciones dentro de AG Grid, que está utilizando cuadros de animación para controlar cuándo se renderizan las cosas, así que hay una combinación de factores en juego allí. Pero sí, definitivamente hubo diferentes enfoques, todos tenían diferentes pros y contras. Y esto es algo que en realidad estoy revisando constantemente también. Así que queremos que AG Grid tenga el mejor performance en todos los diferentes usuarios que tenemos. Y tienes que encontrar ese equilibrio delicado entre, podría haber hecho todo síncrono y simplemente asumir que todos tenían una máquina de desarrollo, y entonces lo habríamos enviado, y luego habrían llegado los casos de uso de usuarios reales, diciendo, ¿por qué la cuadrícula no funciona muy bien? Y creo que también habría sorprendido a los desarrolladores, porque la mayoría de los desarrolladores tienen máquinas más potentes que donde se está utilizando su aplicación. Así que tienes que probar el ciclo de vida completo de donde se utiliza este componente, y luego hacer compromisos sobre eso. Me encanta cómo estás hablando de eso. Anteriormente, estábamos hablando de cómo esta nueva generación de desarrolladores en realidad usa iPads en lugar de máquinas de desarrollo. Y me encanta el hecho de que estás teniendo en cuenta todo eso en tus testing. La siguiente pregunta es, ¿puedes envolver múltiples funciones de actualización de estado en FlushSync y esperar los mismos resultados? Esa es una buena pregunta para recordarme algo complicado con FlushSync, es que si los tienes anidados, React se quejará de ti. Así que no puedes simplemente listar tu base de código con FlushSync, porque si ya está renderizando, y luego intentas hacer un flush de nuevo, te encontrarás con advertencias y errores. Así que sí, no puedes anidarlos. Volviendo a las máquinas de gama baja. ¿Cuáles son algunas técnicas que utilizas para probar el performance de máquinas de gama baja en hardware de gama alta? Bueno, creo que eso es una vez más lo que dijimos que hacer con el throttling, pero luego a veces simplemente necesitas tener en tus manos esos dispositivos. Suena bien, veamos la siguiente. ¿Encuentras algún efecto secundario de la versión 18 de React? Supongo que los efectos secundarios son potencialmente de lo que he hablado. Así que supongo que esos son los principales con los que nos hemos encontrado con esto. Así que la respuesta a eso es no. Así que, no. La respuesta es no. Bueno, veamos, ¿tenemos alguna otra pregunta? Tomaremos una última pregunta. Así que, se está actualizando dinámicamente en mi teléfono. Estoy tratando de seguir el ritmo de todo. Veamos. Una pregunta más. Máquinas lentas, hemos hecho esa pregunta. Sí, tenemos un poco de repetición en las preguntas. Vemos que tenemos una más entrando. Creo que has tomado todas las preguntas, Stephen. Gracias. Gracias por pasar tiempo con nosotros en el Rincón de la Sabiduría. Gracias a mis co-anfitriones por las increíbles preguntas y permitirme ser sabio con Stephen. Muchas gracias.

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit 2020React Summit 2020
125 min
Getting Started with Suspense and Concurrent Rendering in React
Featured Workshop
React keeps on evolving and making hard things easier for the average developer.
One case, where React was not particularly hard but very repetitive, is working with AJAX request. There is always the trinity of loading, success and possible error states that had to be handled each time. But no more as the `<Suspense />` component makes life much easier.
Another case is performance of larger and complex applications. Usually React is fast enough but with a large application rendering components can conflict with user interactions. Concurrent rendering will, mostly automatically, take care of this.
You will learn all about using <Suspense />, showing loading indicators and handling errors. You will see how easy it is to get started with concurrent rendering. You will make suspense even more capable combining it with concurrent rendering, the `useTransition()` hook and the <SuspenseList /> component.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)