Renderizado: ¿Sincronizar o no sincronizar?

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.