Patrones para el Rendimiento

♪ ♪ Entonces, sí, quiero hablarles sobre patterns para performance, porque supongo que ya hemos visto algunas charlas hoy que han estado hablando sobre performance, y como desarrollador de React, eso es algo clave que a muchos de nosotros siempre, supongo, nos importa, importante para nuestros usuarios. Por eso quiero compartir esto con ustedes hoy.

Como trabajo para Azure Grid, habrá algunas cuadrículas presentadas en esta charla. Entonces, ¿puedes decir cuál de estas cuadrículas es mejor? Tenemos la de arriba donde estás redimensionando y está, ya sabes, saltando, o tienes la de abajo donde tienes este redimensionamiento suave. Entonces creo que es obvio cuál querrían usar nuestros usuarios y con cuál querrías trabajar. Y entonces esto es algo en lo que vamos a profundizar y decir cómo resolvimos este problema.

Entonces, como ya saben, trabajo en Azure Grid y nuestra misión es crear la mejor tabla de data de JavaScript o React en el mundo. Entonces, ya sabes, tenemos una versión gratuita. Tenemos versiones enterprise. Así que vengan y descubran más sobre esto porque creemos que es un producto brillante y está mejorando y realmente estamos invirtiendo mucho en nuestro componente React. Así que esperamos que puedan probarlo, pero eso es suficiente sobre Azure Grid. Quieren saber sobre performance.

Entonces, para, supongo, darnos una historia para esta charla, queremos tener esta reconstrucción donde un usuario ha comenzado a usar Azure Grid, una versión muy antigua, que ya no tiene este problema, y dijeron, oh, ya sabes, cuando uso este componente personalizado, la cuadrícula hace este redimensionamiento realmente lento. Entonces piensan, oh, está bien, pero también dicen, bueno, es cuando están usando un renderizador de celdas personalizado. Entonces, para darles, supongo, el trasfondo que necesitan, los renderizadores de celdas personalizados son una forma para ustedes como desarrolladores de React de dar a nuestra cuadrícula un componente funcional o un componente de clase y decir renderiza esto dentro de cada celda. Entonces aquí tenemos una tabla de clima donde en lugar de números, tienes pictogramas basados en cuántos días de sol. Y eso sería su propio componente de React. Entonces, en el caso de uso, tienen que están mostrando un total. Entonces podrían tener un renderizador como este, donde en el cuerpo de su renderizador, tienen una lógica realmente compleja, que es realmente lenta. Y luego simplemente están devolviendo un valor. Quiero decir, esto no va a ser lento, pero solo vayan conmigo y espero que demuestre lo que estamos tratando de mostrar aquí. Y luego para usar este renderizador de celdas, lo pasan a la cuadrícula de esta manera. Encontraremos eso en su columna diciendo, bueno, en realidad renderiza esto con mi renderizador y pásalo al componente AG grid. Entonces volvemos a esta etapa y pensamos, bueno, ¿cómo vamos a resolver este problema? Porque aún no lo hemos notado. Si queremos diagnosticar por qué es lento, necesitamos dar un paso atrás y pensar, bueno, en el caso normal, cuando funciona rápido, ¿cómo se comporta la cuadrícula en esa situación? Entonces tomamos un punto de referencia. Esta es la cuadrícula estándar, sin renderizadores de celdas, y se redimensiona muy suavemente. Vamos a usar el perfilador de React DevTools y lo perfilamos y obtenemos algo como esto. Entonces, mientras estamos redimensionando la columna, tenemos 254 renders en marcha. Eso es un montón de renders, pero son renders realmente rápidos. Por eso no estás viendo realmente ninguna desaceleración a pesar de que hay tantos renders.

Entonces, no siempre más renders es malo. También es, bueno, ¿qué tan lentos son esos renders? Porque React es rápido. React puede renderizar muchas veces sin que su usuario y su aplicación se ralenticen. Así que ahora volvamos al caso del usuario donde sí tienen este problema, y haremos lo mismo. Mira, ahora tenemos menos renders, pero cada uno de estos renderizadores, en lugar de ser menos de un milisegundo, ahora son, ¿qué dice?, 28.9 milisegundos para renderizar ese renderizador total. Y cada uno de estos ahora está bloqueando el hilo principal. Entonces React, en este mismo período de tiempo donde estamos ajustando el tamaño del icono tres, solo puede renderizarlo 10 veces. Y eso es lo que nos está dando esto, ya sabes, salto, salto, salto, porque el navegador no puede repintar suficientes veces para mantenerse al día con él.

Entonces, ¿por qué es lento? Bueno, el componente de celda, se vuelve a renderizar muchas veces. Y vimos que incluso sin nuestro renderizador personalizado, seguía renderizando mucho, pero lo hacía rápido. Introduces este renderizador total, que es un hijo, por lo que también se está renderizando mucho, pero luego tiene un renderizado costoso, que ahora está bloqueando el hilo principal. Y en lugar de todos los renderizados rápidos, ahora tenemos algunos lentos, lo que está causando este comportamiento.

Entonces, ¿por qué se está renderizando tanto? Bueno, en la implementación inicial, teníamos esto, por lo que el componente de celda tenía un estado para el ancho. Y estaba escuchando esta devolución de llamada de nuestro controlador diciendo cada vez que el ancho cambiaba, por lo que cuando se está arrastrando, llamaría a setWidth y establecería el estado, y luego React volvería a renderizar. Así que es el patrón estándar de re-renderizado de estado. Y creo que la masterclass dos veces antes fue, ya sabes, también corriendo en este tipo de problemas de cómo escapamos de este patrón. Solución simple, Memo. Ya sabes, Memo nos permite omitir el re-renderizado del componente hijo. Así que podemos actualizar nuestro código de esta manera. Así que en lugar de pasar el valor render directamente, lo envolvemos en Memo, lo pasamos al renderizador de celdas, y eso nos lleva de vuelta al renderizado rápido. Ahora, si me detengo allí, sería una masterclass muy corta, y estoy seguro de que nada nuevo. Pero, ¿podemos hacerlo mejor que Memo?

Así que vamos a perfilarlo de nuevo, pero ahora con las herramientas de desarrollo de Chrome. Parece que está funcionando bien. Pero si nos fijamos más de cerca, cuando estamos redimensionando, veremos algo como esto. Así que hay muchas y muchas de estas diferentes acciones donde se está re-renderizando mientras cambiamos el lado. Y en total, son unos 81 milisegundos de scripting. Y si nos acercamos a cada uno de esos picos, lo que podemos ver es que tenemos código de AD grid seguido de algún código de React. Y esto está usando el modo de desarrollo para darnos un nombre, supongo, más agradable. Así que podemos ver lo que está haciendo React. Pero lo que puedes ver es que tenemos AD grid haciendo algo, está pintando, y luego tenemos React haciendo algo. Así que esto es, AD grid dice cuál debería ser el ancho, y luego se lo decimos a React, y luego React toma eso, vuelve a renderizar, y hace todo este trabajo extra. Así que Memo todavía va a estar ejecutando código de comparación. Y el comp de celda todavía se está renderizando. Así que aunque hemos detenido el re-renderizado del componente hijo, que era el bloqueador, todavía estamos haciendo potencialmente más trabajo del que necesitamos hacer. ¿Y si no volvemos a renderizar en absoluto? Y aquí es donde a veces hay que mirar nuestro código de aplicación y pensar, bueno, ¿qué es lo que realmente está cambiando aquí? Así que si miramos esta línea de código, lo único que está cambiando el ancho es la propiedad de estilo. Así que en realidad no estamos haciendo ningún cambio estructural en el DOM. Así que cuando vemos esto, pensamos, bueno, en realidad, tal vez no necesito esto en un estado. Tal vez puedo hacerlo yo mismo.

Puedo acceder al DOM y puedo cambiar la propiedad de estilo. Entonces, ¿cómo obtenemos la referencia al div? Bueno, sabes, puedes usar un ref, y puedes establecerlo en el ref, y sabemos que eso nos va a dar una referencia a ese elemento DOM, con el que luego podemos interactuar.

Entonces, dentro de nuestra devolución de llamada podemos usar este efecto para configurarlo en una red, y cambiamos directamente el estilo del DOM. Así que obtenemos el ref solitario, obtenemos el actual, y luego para esa propiedad de estilo, ahora estamos cambiando el ancho. Y esto va a tener exactamente el mismo impacto en nuestro componente que lo que React eventualmente haría después de haber renderizado, averiguado qué ha cambiado, y producido la nueva salida. Así que podemos saltarnos todo eso, y decir, bueno, en realidad, lo único que está cambiando es esto. Voy a cambiarlo quirúrgicamente yo mismo. Y ahora, si volvemos a perfilarlo de nuevo con este cambio, estamos bajando a 31 milisegundos. Así que es una caída masiva, porque simplemente hemos dicho, bueno, sé lo que estoy haciendo, déjame hacerlo yo mismo, usa el navegador, ya sabes, refiérelo de la manera que podemos hacerlo. Así que ahora, cuando estamos redimensionando, solo tenemos código de ag-grid, y el navegador está repintando.

Así que creo que esto es algo que necesitamos recordar. Estamos trabajando en React, pero también estamos trabajando en el navegador. Y el navegador tiene herramientas y formas para que nosotros actualicemos cosas que podemos usar para un buen efecto. Y así es como un ejemplo de donde podemos hacer eso. Y así hemos pasado de esto con react-memo a la actualización-directa-de-estilo, que nos está dando una experiencia de usuario mucho mejor. Y también, algo a tener en cuenta aquí es que no solo es una mejor experiencia de usuario si el usuario ha recordado usar memo, esto también va a funcionar si el usuario no lo ha hecho, el desarrollador no ha envuelto su componente en memo. Así que hemos permitido que nuestra cuadrícula sea mucho más robusta a cómo se está configurando. Y eso es algo que es importante porque incluso si los desarrolladores están tomando decisiones subóptimas como una biblioteca de aplicaciones, queremos tratar de darles la mejor oportunidad para que nuestro producto funcione lo más rápido que pueda.

Pero necesitamos tener cuidado. El código que hemos mostrado hasta ahora en realidad tiene un error bastante grande. No sé si alguien tiene alguna idea de lo que podría ser, pero veremos esto. Así que hicimos estos cambios, pero de repente las columnas empiezan a parpadear en su lugar. Así que cargas tu cuadrícula, y puedes ver que todas ellas están alineadas sobre la primera. Así que lo que está pasando ahora es que estamos usando un efecto. Y un efecto se ejecuta de forma asíncrona después de que el navegador ha pintado. Así que lo que tenemos aquí es que React está renderizando todas nuestras columnas, pintándolas en el navegador, y luego está ejecutando el efecto, que luego está entrando y cambiando el estilo directamente, por eso tenemos columnas todas en un lugar y luego de repente saltan. Así que no queremos esto, porque esto es aún peor. Entonces, ¿cómo podemos establecer este ancho inicial? Porque no puedes simplemente ponerlo en un estado y luego tener tu manipulación de estilo directo, porque la próxima vez que se renderice, lo que estaba en el valor del estado va a sobrescribir lo que has hecho. Así que vas a tener que averiguar, bueno, ¿cuál debería estar leyendo y cuál es la fuente de la verdad? Pero tenemos estos dos enfoques alternativos. Así que el primero es usar el efecto de diseño y luego el use ref como una devolución de llamada.

Así que me encanta esto. Cuando tomé esta captura de los documentos, fue como, oh, está bien. Así que hay esta trampa. Use layout effect puede dañar el performance, pero en realidad lo estamos utilizando para mejorar el performance de nuestra aplicación. Así que tienes que profundizar en, bueno, ¿por qué podría esto perjudicar el performance, pero por qué en este caso de uso en realidad nos está ayudando a tener un mejor performance en nuestra aplicación? Y la diferencia clave aquí es que use layout effect. Es como use effect, pero se dispara antes de que el navegador repinte la pantalla y es sincrónico. Así que cualquier código que coloques en un use layout effect va a bloquear la pintura del navegador. Por eso puede ser una trampa. Así que si tienes algún código costoso, sabes, colocado allí, va a retrasar el tiempo que el navegador tiene para repintar. No sé si estoy haciendo sentido. Por eso la mayoría de las veces dice usar un efecto porque los efectos secundarios, podrían ser pesados. Y entonces, sí, quieres que el navegador pinte y luego ejecutes esos. No quieres tener que bloquear esa pintura.

Pero hacemos el cambio simple. Cambiamos use effect por use layout effect. No tenemos que cambiar nada más y ahora este código se está ejecutando de forma sincrónica. Así que el ancho se aplica antes de que se renderice la columna. Así que no obtenemos este salto. Así que esto lo soluciona. Así que es una solución viable para ello. Pero hay algunas desventajas potenciales y eso es el uso de layout effect. Se va a ejecutar sin importar si esta celda está montada en el DOM o no. Así que podría ser renderizada condicionalmente pero la lógica en este use layout effect porque depende del componente en sí, si vuelvo atrás verás que tiene esto, el array de dependencias vacío. Así que cada vez que este componente se renderiza por primera vez este código se va a ejecutar. Así que si hay algo en él que es ligeramente costoso, se va a ejecutar cada vez. Y también se ejecuta dos veces en modo estricto lo que puede significar que tienes que tomar otras acciones. Y hay un buen post en el blog de Dominic sobre cómo evitar efectos con callback refs. Y entonces este es un patrón que creo es un enfoque aún mejor para resolver este problema.

Entonces, probablemente todos estamos muy acostumbrados a tener use ref en nuestro código donde defines la ref y luego la pasas al elemento div y luego sabes que esa ref va a estar definida. Pero si inspeccionamos el tipo de eso de cerca también hay un callback. Así que en realidad podemos darle una función. Entonces definimos una ref como de costumbre porque todavía queremos poder hacer referencia a nuestro elemento div para la celda. Pero luego definimos un callback. Entonces vamos a decir set ref y este callback recibirá una referencia al div o null. Y pasas ese callback a la ref. Y lo bueno de esto es que este callback solo se va a ejecutar cuando este elemento div específico esté montado. Así que si las cosas se renderizan condicionalmente esto, el código que configuras en tu callback para esta referencia solo se va a ejecutar cuando el div esté realmente montado. Y luego puede obtener null porque React llamará a esto de nuevo cuando ese elemento esté desmontado. Ahora es crucial que uses, envuelvas esto en un useCallback porque si no lo haces entonces en cada render este React lo volverá a llamar con una nueva ref. Así que el callback ahí es esencial. Entonces, si volvemos y actualizamos nuestro código para nuestra referencia de celda, se verá algo así. Definimos nuestra referencia y configuramos este callback. Y ahora dentro de este callback hacemos el mismo código donde escuchamos a nuestro controlador de celda para los cambios de ancho y aplicamos el estilo directamente. Y esto ahora funciona, se ejecuta de forma sincrónica para empezar y luego también nos permite actualizar el ancho de forma dinámica o directamente sin causar ninguna renderización. Así que creo que repasé estos. Lo llamas, ref con los elementos a ser montados, se va a llamar de nuevo cuando esté desmontado, se ejecuta de forma sincrónica que es clave para nosotros y solo se ejecuta una vez. Así que puedes evitar algo de la lógica del modo estricto si necesitas.

Entonces, el resultado final es que, no importa lo que el usuario introduzca o el desarrollador introduzca, ahora estamos protegidos contra renderizaciones lentas porque no necesitamos volver a renderizar cuando solo estamos cambiando el ancho de esta columna. Así que tenemos dos renderizaciones aquí en lugar de 254, lo cual creo que es una gran victoria. Pero algunas conclusiones mientras termino aquí. Así que React es rápido. No tienes que optimizar todo prematuramente. Así que espera hasta que tengas un problema de performance antes de empezar a añadir esta complejidad a tu aplicación. Como viste, memo probablemente sea suficiente, pero con Agigrid queríamos llevarlo al límite. Queríamos asegurarnos de que no importa cuántos data usuarios introduzcan en nuestra cuadrícula, queríamos asegurarnos de que la cuadrícula todavía se desempeñara porque después de todo, eso es por lo que la gente elige usar Agigrid. Así que necesitábamos hacerlo lo más rápido que pudiéramos. Y tomar control directo, puede llevar a estas ganancias de performance, pero asegúrate de usar la herramienta correcta como vimos en los diferentes enfoques para usar la referencia para que no termines introduciendo nuevos errores en tu código. Muchas gracias por escuchar. Espero que esto sea útil.

Entonces, bien, comencemos con esto. Algo de soporte técnico, por favor. Nuestra licencia de Agigrid tiene espacios, algo así como mi empresa. Esto nos impide agregarla en el archivo .env. Nos gustaría ocultarla de Copilot. Vale, sí. Como en, tienes una licencia, así que envía un ticket de soporte y lo investigaremos para ti. Bien hecho, pasemos al siguiente.

¿Esto se aplica a React en general o solo para el caso de uso específico de Agigrid, nosotros no usamos Agigrid? Sí, el código que he mostrado es solo específico de React. Este enfoque puede ser utilizado. Así que supongo que lo importante será no llevarse de esta charla... Bueno, sí quiero decir, sí, Agigrid es genial. Pero espero que también te dé esa idea si me encuentro con un problema de rendimiento, ¿cuáles son los enfoques que puedo tomar? Así que supongo que esta mañana, se habló sobre el uso de la cola de micro tareas. Este es otro enfoque donde lo clave aquí es decir, bueno, ¿qué está cambiando cuando estoy actualizando mi estado? ¿Es algo de lo que podrías encargarte tú mismo con las API del navegador? Y si no necesitas usar lo que React nos da en términos de luego averiguar qué elementos del DOM han cambiado y usando el DOM virtual, entonces eso es algo que puedes buscar controlar tú mismo.

Me encanta esa respuesta. Muchas gracias por eso. ¿Y qué pasa si una celda personalizada necesita cálculos internos basados en el ancho? Sí. Entonces esa lógica puede hacerse usando, de nuevo, las API del navegador. Creo que hay formas de monitorear cuán ancho es tu contenedor. Creo que es el observador de mutaciones. Hay formas de hacer eso. Pero esta es una pregunta válida porque supongo que apunta a, bueno, ¿qué pasa si el ancho se pasó como una propiedad? Y entonces si eso fuera parte de nuestra interfaz para decir, te damos el ancho, entonces no podríamos usar este truco. Así es donde estás limitado por el código que tienes. Y si el ancho era una propiedad que pasamos a estos renderizadores personalizados, entonces sí, no podríamos hacer esto y tendríamos que asegurarnos de que las cosas estuvieran memorizadas correctamente. Pero de nuevo, como el ancho es una propiedad, rompería, useMemo lo haría. O el memo aún renderizaría el componente hijo. Así que para nosotros, fue, bueno, en realidad, la mayoría de los renderizadores de celdas personalizadas están escritos de una manera que son dinámicos y pueden cambiar de tamaño dentro de eso por lo que no queremos pasar el ancho hacia abajo y encontrarnos con este problema.

John dice, hola, gran trabajo con AG grid. Gracias, John. ¿Cómo te comparas con la tabla TanStack? Sí, nos encanta la tabla TanStack.

Y creo que podrías, si miras de cerca, patrocinamos a Tano debido al trabajo que están realizando. Y nos vemos a nosotros mismos no como competidores, sino como en dos enfoques diferentes para resolver el mismo problema. Entonces, como para AG Grid, nos gusta decir que incluye baterías. Solo tienes que soltar nuestro componente en tu página y se encarga de, y se encarga de ello por ti, mostrando todas las filas, mostrando los encabezados, las celdas. Solo estás configurándolo. Mientras que con la tabla TanStack, tienes que escribir todos los componentes de la interfaz de usuario por ti mismo. Tienes que escribir tus celdas, tus encabezados. Te da todos los bloques de construcción como una tabla headless y la funcionalidad para decir qué filas se mostrarán pero eso depende de ti. Entonces sí, la tabla TanStack es mucho más ligera porque está haciendo mucho menos, pero AG Grid es mucho más para soltarla en la aplicación, completamente funcional desde el principio, sin trabajo real para ti que hacer, especialmente porque también es gratis, bueno, nivel gratuito y uno advanced.

¿Tienes alguna recomendación de libros o cursos para aprender sobre patterns para performance? Bueno. ¿Estás construyendo uno? No estoy construyendo uno. Pero mientras leía, escuché a alguien en Twitter ayer que ha escrito un libro advanced. Y entonces, tendría que encontrarlo. No recuerdo su nombre de memoria. Tal vez ya los conozcas. Pero sí, definitivamente hay cursos por ahí. No puedo recordar, sin embargo. Vale. Lo siento. Está bien. Y aquí estamos.

Vale. ¿Es este un patrón que utilizas a menudo o es un ejemplo muy específico para este caso de uso? Creo que es un ejemplo específico para este caso de uso. Pero de nuevo, vuelve a ese punto de detectar estos patterns. Así que es como si te encuentras con esto en una situación diferente donde podrías ver que está sucediendo algo similar, entonces puedes aplicar este patrón de nuevo. Así que sí, puede parecer muy específico para ese caso de uso pero creo que lo importante a tener en cuenta es que hay un patrón aquí que podemos aplicar si nos encontramos con esta situación de nuevo.

¿Son los efectos secundarios en un callback de set esencialmente un truco? Efectos secundarios en un callback de set ref. Déjame pensar en eso. Podemos volver a ello. Sí. Dije que se refiere a lo que quiero decir con efectos secundarios. Supongo que hay algo que estás... Supongo que tienes que ser consciente de la forma en que se están ejecutando estos callbacks y que son el sincrónico, así que hay algunas cosas en él que podrías querer evitar. Pero supongo, ya sabes, si es un truco... No sé, ya sabes, muchas de las cosas que hacemos, algunas personas dirán, bueno, ese no es el patrón estándar, así que es un truco. Pero creo que cuando estás empujando los límites, a veces necesitas salir del camino estándar. Así que, pero entonces eso es también donde, tal vez no alcances para estos inicialmente, solo ve por ello cuando lo necesites.

¿Y qué sucede si necesitas persistir el ancho de la columna para las próximas ejecuciones de la aplicación o en una aplicación con pestañas? Bueno, esa es una gran pregunta. Creo que sé quién está haciendo esa pregunta.

Así que en nuestra próxima versión, en la versión 31, que saldrá a finales de noviembre, parece que tienen información privilegiada. Vamos a añadir una nueva característica, que es como el ancho inicial, donde, cuando cambias de pestaña en tu cuadrícula o la destruyes, puedes obtener el estado de la cuadrícula. Y luego, cuando vuelvas a la pestaña, pasas ese mismo objeto a la cuadrícula y restaurará la cuadrícula al mismo ancho, ya sabes, el mismo ancho de columna, el mismo orden, y recuerda todo ese estado para ti. Y eso es algo que sabemos que la gente ha estado haciendo. Así que sí, en la 31, que saldrá a finales de noviembre, esa característica va a ser implementada. Muy buena pregunta, y nos deja algo que esperar también. ¿Y el useLayoutEffect seguirá haciendo saltar las celdas cuando se usa SSR antes de que se ejecute el código de React? Sí, así que sí, sé que definitivamente hay algunos problemas con useLayoutEffect y la renderización en el servidor. Supongo que en nuestro caso, no soportamos, la renderización completa en el servidor de la cuadrícula porque cuando estás subiendo data dinámica o tienes data, no tiene mucho sentido renderizar eso en el servidor. Así que no me he metido mucho en esto, pero definitivamente soy consciente de que sí, podrías tener problemas con esto. ¿Y cuál es el error más frecuente que cometen los desarrolladores al hacer renderizadores de celdas personalizados? Además, ¿qué determina cuándo o si el renderizador de celdas personalizado se ejecutará? ¿Errores más frecuentes? Creo que la gente no tiende a cometer demasiados errores con sus renderizadores de celdas porque generalmente entonces, ya sabes, estás escribiendo tu propio componente. Supongo que si estás haciendo algo realmente costoso allí, entonces eso podría ser considerado un error porque si vas a tener muchas filas de data, ya sabes, de repente vas a tener muchas de estas renderizadas en tu navegador, aunque nosotros virtualizamos las filas. Así que sólo se renderiza lo que ves. ¿Qué determina si se actualiza? Así que esto, se basará en la data. Así que si actualizas la data de la fila para esa fila entonces se volverá a renderizar. Sí, hay otras cosas en ese objeto de parámetros que lo desencadenarán, pero lo principal es cuando se actualiza la data. ¿Y hay algún inconveniente en ejecutar efectos en un callback de ref? Diría que el único inconveniente es potencialmente, hay un poco más de código en el que pensar, ya sabes, como el post que enlacé de Dominic, él está diciendo, bueno, en realidad, puedes prescindir del user effect y usar estos en su lugar. Así que no diría que hay inconvenientes en usar estos callbacks aparte del hecho de que es quizás otro concepto que tenemos que aprender y quizás si tienes diferentes personas mirando tu base de código, de repente estás viendo un patrón diferente, que luego necesitas educar a la gente sobre él. Así que ese es quizás el inconveniente. Y tenemos tiempo para una más, que es una interesante. Una pequeña cosa, creo que usar useRef en ese ejemplo parece redundante. El evento podría estar directamente adjunto al ref. Sí, este es un problema con el código de demostración. Cortas otros bits y luego de repente las cosas se vuelven redundantes. Así que sí, podrías hacer eso, pero ya sabes, hay otras partes donde vamos a reutilizar ese mismo ref, por eso todavía está ahí, pero sí, buen ojo. Tenemos literalmente 20 segundos. Así que quizás podemos responder a esto muy, muy rápidamente. No entiendo el salto. El ancho no es cero al principio. ¿No es auto antes de useEffect? Auto antes de useEffect. Bueno, en la implementación de esta demostración, el ancho es cero. Así que es, sí, probablemente hay más que hablar allí. Increíble. Wow. Esa fue una presentación increíble, icónica, fabulosa. Muchas gracias, Stephen. ¿Podemos dar un aplauso, por favor? Gracias. Debería estar bien. Gracias. De nada.