What Refs Can Do for You

Hoy, quiero hablarles sobre lo que los refs pueden hacer por ustedes. Como ya han tenido algunos adelantos y aquí hay más información sobre, ya saben, yo. Así que hay 10 años en la industria financiera y ahora tres años con Agigrid. Y tuve que añadir esto a mi diapositiva, ya saben, fotos de las mascotas, ya que todos van a enterarse de ellas. Así que son Toby, Rufus y Coco. Así que sí, la vida está ocupada en casa. Pero esa es mi vida personal.

En un entorno profesional, trabajo en Agigrid. Así que todos han escuchado los anuncios hoy, tenemos Agigrid y los AgiCharts. Así que pueden incorporar estos componentes en su aplicación, comenzar a usarlos y tener todas estas grandes características. Pero no se preocupen, eso no es en lo que me voy a centrar hoy. Voy a compartir algunas de las cosas que he aprendido mientras perfilaba Agigrid. Y estas son cosas que creo que a medida que avanzamos en este viaje juntos, caminamos a través de los problemas, deberíamos aprender algo sobre estas diferentes partes de React, o al menos ese es mi objetivo.

Así que comencemos aquí. Así que mientras desarrollábamos Agigrid, estábamos ejecutando estos diferentes casos de uso. Y uno de ellos fue, bueno, un usuario viene a nosotros y dice, tengo este componente personalizado que voy a poner en una de estas columnas. Así que en este caso, es como un ticker con una imagen de la empresa. Y van a redimensionarlo. Y lo que notamos en estas pruebas es que, bueno, en realidad, el redimensionamiento era realmente brusco. Y ellos dicen, esta es una experiencia de usuario terrible. Así que es como, OK, ¿qué vamos a hacer al respecto? Vamos a investigar.

Así que antes de saltar al caso complicado de esta situación, demos un paso atrás y veamos, ¿podemos realmente reproducir esto en un caso más simple y ver si hay algún problema de rendimiento allí? Así que abrimos React DevTools. Quité todos los renderizadores de celdas personalizados. Así que aquí solo estamos renderizando celdas de texto plano, movimos la columna y grabamos el perfil. Y esto es lo que vimos. Así que no estamos viendo ningún problema de rendimiento percibido en esta situación. Pero lo que pueden ver es que tenemos 254 renderizaciones solo por hacer algunos de estos redimensionamientos. Pero son renderizaciones rápidas. Así que en realidad no tenemos automáticamente un problema aquí porque tenemos muchas renderizaciones. Pero es algo que tal vez necesitemos considerar.

Y mientras miramos el perfil, estas son dos configuraciones que creo que son muy, muy importantes. Así que grabar que el componente Y se vuelve a renderizar. Así que esto te está diciendo, bueno, es el componente de celda, y fue el hook 30 el que cambió. Y luego hay otra configuración en el panel de componentes donde puede analizar los nombres de los hooks. Así que en lugar de tener este indefinido falso, falso, falso, en realidad te da los nombres que usaste en tu código. Así que estas son solo pequeñas cosas que pueden hacer que la depuración de estos problemas sea mucho más fácil.

Como dije, realmente no vimos este problema de rendimiento en el caso simple. Así que ahora ponemos un componente de celda personalizado, y lo hacemos artificialmente lento. Así que pondremos algo de lógica lenta allí, tal vez como un bucle for, que hace mucho trabajo, antes de renderizar las cosas. Así que estas son solo una idea de simular lo que un usuario podría proporcionarnos. Porque no estamos en control de lo que el usuario nos va a dar. Pero necesitamos asegurarnos de que la cuadrícula aún funcione bien en esas situaciones.

Así que cuando hicimos esto, lo pusimos en la cuadrícula, pudimos ver que teníamos este comportamiento lento nuevamente. Y esta vez en el perfil, se ve bastante diferente. Solo hemos logrado renderizarlo 10 veces. Así que esta es la razón por la que en lugar de tener muchas, muchas, muchas renderizaciones diferentes, y obtienes ese redimensionamiento suave, en su lugar tenemos esto, ya sabes, el navegador se queda atascado, se vuelve a renderizar. El navegador se queda atascado, se vuelve a renderizar. Así que puedes ver esto con las barras mucho más altas y el tiempo que estaban tomando. Y también podemos ver bastante claramente que es esta celda del ticker que hemos proporcionado, que es el cuello de botella, y que está bloqueando el navegador.

Así que si miramos rápidamente esto y decimos, bueno, ¿por qué se está renderizando tanto este componente? Ahora, en nuestro componente de celda, estábamos configurando el estilo a través de la propiedad de estado, digamos que tenemos left aquí. Así que nuestro controlador de celdas, que es lo que controla dónde están todas estas columnas, estaba diciendo, bueno, la posición izquierda está cambiando. Y eso es lo que esperarías. Y simplemente actualizaríamos el estado. Pero debido a que estamos actualizando el estado, React está volviendo a renderizar todo este componente. Y debido a que el estado se está actualizando en ese div, la celda personalizada es un hijo de eso. Y así, si no hay memorización o algún tipo de cachés allí, eso también se está volviendo a renderizar. Así que el primer paso es, bueno, podemos envolverlo y usar memo, o memo. Y luego también esto es algo de lo que el compilador de React se encargará por nosotros. Así que no voy a pasar mucho tiempo hablando de eso. Eso nos ayuda a mejorar el rendimiento.

Y eso podría ser lo suficientemente bueno. Pero, ¿podemos realmente hacerlo mejor que memo, o el compilador? Y creo que la respuesta es sí. Pero para demostrar esto, ahora necesitamos echar un vistazo al panel de rendimiento real. Y grabaremos un perfil mientras hacemos esto en Chrome DevTools aquí. Y lo que ves es algo como esto. Muchas y muchas de estas líneas muy largas, donde muchas funciones profundamente anidadas han sido ejecutadas. Pero si hacemos zoom en una de estas pistas individuales, y luego comenzamos a mirar el código que está siendo ejecutado, vemos que tenemos esta sección de Agigrid, que es la lógica que determina a dónde va esta columna. Y luego tenemos una segunda parte de React. Así que esto está en modo de desarrollo de React, por lo que puedes ver los nombres de las funciones. Así que aunque en producción eso sería más pequeño y más corto, todavía existe esta noción de que hay código de Agigrid determinando qué necesita cambiar y luego React está respondiendo y haciendo esos cambios por ti. Y así en esto, puedes ver que el componente de celda se está renderizando muchas veces. O teníamos muchos componentes de celda en la página que han sido renderizados. Así que como dije, ¿qué pasa si no volvemos a renderizar en absoluto? Ahora para pensar en esto, si miramos nuevamente el componente que teníamos, lo único que estábamos cambiando cuando movíamos las columnas era en realidad una posición de estilo. Es solo esta posición left. Entonces, ¿podemos realmente actualizar esto manualmente? Así que si tuviéramos una referencia al elemento dev, podríamos establecer la propiedad left nosotros mismos. Porque en el fondo, eso es todo lo que React va a terminar haciendo. Porque eso es lo único que hemos cambiado entre esos renderizados. Entonces, ¿qué pasa si lo hacemos nosotros mismos? Pero entonces la pregunta es, bueno, ¿cómo obtenemos una referencia a ese div? Y aquí es donde podemos usar ref. Así que creamos un ref, cell ref equals use ref. Y luego dentro de nuestra plantilla, podemos establecer eso en nuestra propiedad ref. Y luego configuramos nuestro controlador de celda y actualizamos el estilo manualmente. Pero, ¿alguien puede ver cuál podría ser el problema aquí? Bueno, la ref de la celda posiblemente sea indefinida. Así que en el renderizado inicial, este método on left change, eso podría realmente ejecutar esta lógica. Y podría ejecutar el callback para intentar establecer esta propiedad left. Pero en ese momento, la ref de la celda aún no ha sido asignada. Así que va a fallar. Entonces pensamos, oh, está bien, bueno, ¿qué pasa si envuelvo esto en un news effect? Porque sé que la ref va a estar definida una vez que se llame al efecto. Así que podemos hacer este cambio. Pero luego necesitamos tener cuidado, porque en realidad hemos creado un error masivo aquí. Así que ahora en el renderizado inicial, todas las columnas están alineadas en la primera.

Entonces, lo que puedes ver es que todas esas propiedades iniciales left no se están estableciendo a tiempo. Así que el navegador está realmente renderizando antes de que logremos establecerlas. Y ahora esto tiene sentido en la forma en que se ejecuta useEffect. Porque useEffect se ejecuta de manera asíncrona después de que el navegador se ha pintado. Así que las columnas se renderizan sin posición left, luego establecemos el estilo, y las columnas saltan a su posición. Y esto es completamente intencionado. UseEffect no está diseñado para bloquear el pintado del navegador. Así que en realidad no es lo adecuado para nuestro caso de uso.

Así que podríamos tener dos ideas diferentes. Entonces dices, bueno, o tal vez puedo proporcionar un valor inicial left a la plantilla a través del estado, luego comenzaré a actualizarlo. O tal vez solo necesito encontrar una manera de forzar al navegador a ejecutarse de manera síncrona. Así que si miramos este enfoque, tal vez aquí agreguemos un encadenamiento opcional para manejar el hecho de que está indefinido. Y estableceremos el estilo con una propiedad inicial left. Pero yo diría que no hagas esto en absoluto. Así que React no sabe sobre los cambios de estilo directos que estás haciendo. Así que luego, en un renderizado futuro, podría volver y decir, bueno, está bien, tengo esta propiedad inicial left, voy a volver a renderizar, y voy a establecer el estilo a eso. Así que no quieres mezclar y combinar estas versiones, porque entonces no estás trabajando con React, en realidad estás luchando contra él, y podrías encontrarte en situaciones realmente malas y desordenadas.

Así que no podemos hacer eso. Pero sí conocemos useLayoutEffect. Y así, la diferencia con useLayoutEffect es que es la versión de useEffect, pero se ejecuta de manera síncrona antes de que el navegador repinte la pantalla.

Y ahora hay una gran trampa que se menciona en la documentación en términos de rendimiento, y es porque estás haciendo todo ese tipo de trabajo antes de que el navegador se pinte, por lo que lo estás bloqueando. Así que el código que deberías estar ejecutando en useEffect no necesariamente debería moverse a un useLayoutEffect. Pero podemos hacer este cambio. Así que lo intercambiaremos por useEffect, se ejecutará de manera síncrona, y ese valor inicial left realmente se aplica antes de que el navegador se pinte. Así que ahora hemos solucionado efectivamente nuestro problema, y eso funciona. Pero hay algunos inconvenientes, y hay algunas cosas que hacen que esto tal vez no sea la solución óptima. Pero volveremos a ellos más adelante en la masterclass.

Entonces, ¿no se trata esta masterclass sobre refs? Bueno, sí, lo es. Así que estamos acostumbrados a ver refs definidos de esta manera. Así que decimos, useRef, nos da este objeto ref, y luego lo pasamos a la propiedad ref en nuestro desarrollo, y eso se asignará de manera asíncrona. Pero si inspeccionamos el tipo de la propiedad ref, así como el objeto ref, que podemos pasar, también hay un ref callback. Y lo que esto significa es que realmente puedes definir una función. Y esta función, cuando se pasa a la propiedad ref, va a comportarse de esta manera. Así que cuando un elemento dev es, o cualquier elemento al que lo apliques, es montado por React, este callback será llamado con una referencia a ese elemento HTML. Y luego, cuando, por cualquier razón, ese elemento tal vez sea eliminado del DOM, este callback será llamado nuevamente pero con none. Bueno, así es como funciona en React 18, al menos. Y es muy importante, si sigues este enfoque, que envuelvas esto con useCallback. O tal vez cuando comiences a usar Compiler, eso ya no sea necesario. Porque en cualquier momento, si no usaste useCallback, sería una nueva función, forzaría un render, y luego entrarías en esto, podrías entrar en un pequeño bucle. Así que recuerda el useCallback para este enfoque. Como dije, se llama cuando se monta, se llama nuevamente con null cuando se desmonta, y esto se ejecuta de manera síncrona antes de pintar. Y también en la versión 18, no se ve afectado por el modo estricto. Así que así es como podríamos actualizar nuestro código para usar un ref callback. Así que cuando se nos da el ref y está definido, podemos configurar nuestra escucha para que podamos ajustar la posición left. Y porque se ejecuta de manera síncrona, ese inicial, podemos establecer la posición antes de que se renderice. Y luego otra cosa buena de este enfoque es que ahora hemos eliminado esos renders por completo. Así que todos los renders que teníamos, donde estábamos actualizando el estado o teniendo cosas, se han ido. Pero el resultado final es que todavía tenemos este navegador realmente agradable, operando de manera fluida, porque el único código que ahora se está ejecutando es nuestro código de AG Grid, para determinar dónde necesita estar, y luego establecer ese estilo del navegador. Así que básicamente hemos eliminado todo el código de React, que solo estaba duplicando lo que ya sabíamos hacer. Ahora, con React 19, casi aquí, estos son algunos cambios que realmente están afectando el enfoque del ref callback.

Entonces, en la versión 18, necesitas ese use callback, y también te dará un null cuando el elemento se desmonte. Pero a partir de la versión 19, puedes escribir esto de una manera más agradable. Así que si devuelves una función de limpieza, entonces React no la llamará con un valor null. En su lugar, solo ejecutará la función de limpieza, por lo que es mucho más cercano a cómo definimos useEffect y useLayoutEffect. Así que es una mejora de DX realmente agradable. Y además, ahora se llamará dos veces en modo estricto. Así que se está volviendo mucho más cercano a cómo definirías tus efectos.

Ahora, sí, tenemos tiempo. Así que esto es, si volvemos a useLayoutEffect y por qué podría ser la desventaja de usarlo. Es porque tienes este problema potencial si estás haciendo renderizado condicional. Así que si un elemento se renderiza condicionalmente, useLayoutEffect aún se ejecutará porque está vinculado a la duración de vida de ese componente. Así que si, en el renderizado inicial de este componente, si el indicador de celda visible está configurado en false, ese div no se montará. Pero nuestro useLayoutEffect, eso aún se ejecutará. Así que si en algún momento decimos, bueno, esta celda ahora debería ser visible, tenemos que asegurarnos de que tenemos nuestro array de dependencias coincidiendo con la salida condicional porque necesitamos asegurarnos de volver a ejecutar este efecto de diseño para poder acceder a ese div y hacer el código que queramos hacer. Pero la complejidad podría venir del hecho de que podrías no saber o tener control de las variables de estado exactas que cambian el renderizado condicional de este elemento. Así que esto es algo donde useLayoutEffect no es tan fácil. Y si miramos nuestro enfoque de ref callback aquí, así que definiremos nuestro setRef, y nota que no tenemos que preocuparnos por las dependencias de lo que hace que esa celda sea visible porque cada vez que React termina montando este elemento div, ejecutará ese callback setRef, y podemos configurar el código que necesitamos. Así que en lugar de la, supongo, la sincronización y el ciclo de vida estando vinculados al componente, estos ref callbacks están realmente bien adjuntos al elemento div con el que realmente quieres trabajar. Así que elimina esa complejidad de la ecuación. Esto es algo que puedes leer un poco más en el blog de Dominic sobre evitar useEffect con callback refs. Así que él tiene algunos otros ejemplos también de dónde esto funciona bien.

Así que algunas conclusiones. Así que React es rápido, y especialmente con el compilador saliendo y con Memo, eso podría ser suficiente para ti. Pero si quieres tomar el control directo, hay ganancias de rendimiento que se pueden lograr. Y esto es algo que hemos hecho en AgGrid. Y estamos viendo cómo una ref prop puede tomar una función de callback para darte todas las ventajas que acabamos de describir. Pero recuerda, con gran poder viene gran responsabilidad. Así que asegúrate de usar estas herramientas solo cuando las necesites. No empieces a esparcirlas por todo tu código cuando en realidad ejecutar algún código en el useEffect es suficiente.

Así que usa esto si lo necesitas, pero no intentes ser demasiado ingenioso. Y eso es lo que los refs pueden hacer por ti.

Gracias. -. Primera pregunta. ¿Cuál fue la herramienta que usaste para monitorear el número de re-renders e identificar por qué ocurrió un re-render? ¿Cómo conseguiste eso? Así que eso es React DevTools. Así que es una extensión que puedes instalar desde, supongo, Chrome o Firefox u otros navegadores son compatibles. Pero sí, una vez que has instalado esa extensión en tus DevTools, es DevTools, consola, ¿cuál es, presiona F12, eso es lo que hago. O haz clic derecho y di Inspeccionar. Y luego verás React en tu panel y puedes hacer clic en el botón de grabar allí y comenzar a interactuar con tu aplicación.

Y luego, cuando detienes la grabación, el perfilador de React DevTools te mostrará todos los renders que han ocurrido. -. Suena realmente útil. Sí, hay otras masterclass, ya sabes, que profundizan en eso y cómo puedes usar el perfilador para detectar estas cosas. Genial. Ooh, tenemos algunas preguntas técnicas profundas. Esto será divertido. ¿Consideraste usar variables CSS en lugar de establecer el estilo directamente desde JavaScript? Si es así, ¿por qué optaste por establecer el estilo desde JS? Me interesaría saber cómo manejarías la diferencia. Entonces, ya sabes, ¿cómo respondes a la acción del usuario y luego aplicas eso a las celdas también? Así que creo que siempre va a necesitar algún tipo de JavaScript involucrado para actualizar esas cosas. Y hay muchos casos de uso diferentes sobre por qué podrías necesitar mover columnas. No siempre se trata solo de, ya sabes, el usuario haciéndolo. Podríamos tener características donde es, como, quieres autoajustar tus columnas. Así que cuando comienzas a autoajustar columnas basadas en su contenido, entonces necesitas mover otras columnas. Así que hay bastante lógica compleja cuando estás agregando todas estas características diferentes. Digamos, como, mi columna fija, todo lo demás necesita moverse. Así que por eso necesitamos esto en JavaScript. Sí. Tiene sentido.

Genial. ¿Es posible que React simplemente no fuera la herramienta adecuada para el trabajo aquí? Esto parece mucha complejidad añadida para trabajar alrededor del ciclo de renderizado de React. Entonces, quiero decir, tenemos... Azure Grid funciona en JavaScript puro. Funciona para todos los diferentes frameworks. Funciona en React. Y esto es una cuestión de compensación.

Entonces, ya sabes, había una versión anterior de Azure Grid donde era solo JavaScript puro de principio a fin. Y podrías tener esto ahora. Podrías crear un Azure Grid en JavaScript puro dentro de tu aplicación. Y entonces no habría React dentro de él. Pero al hacer eso, pierdes la experiencia de autoría tipo DX de poner componentes de React dentro de tu grid. Así que para la gran mayoría de nuestros usuarios, es más importante que en React, que puedan decir, bueno, tengo un componente de React. Déjame poner esto como la celda. Déjame poner esto como el encabezado personalizado. Así que todas esas mejoras en DX superan. Y luego podemos trabajar duro nosotros mismos para asegurarnos de que el rendimiento sea tan bueno como pueda ser, en lugar de tener esa complejidad de poner un componente de React y estar mirando las herramientas de desarrollo y no ver realmente un árbol de componentes de React.

Sí, las mejoras en DX son bastante agradables. Sí. Genial.

Pregunta. Oh, esta tiene muchos votos. ¿Qué pasa si React vuelve a renderizar el componente? ¿No perderías los estilos en línea hechos con el ref? ¿Hay garantía de que el componente no se volverá a renderizar? Así que aquí es donde, supongo, estamos trabajando en... Estás trabajando en esto, que React no toque cosas de las que no tiene control o que no se le ha dicho que actualice. Así que sí, esto es algo en lo que hemos investigado y no hemos tenido problemas con ello todavía. Pero, ya sabes, esa es una pregunta válida. Bien.

Esta podría ser respondida por el trabajo del compilador que mencionaste. ¿Es necesario el hook de callback para el ref de callback en React 19? No esperaría que lo fuera. Porque, ya sabes, en otros lugares donde podemos definir funciones en línea, creo que eso se está resolviendo. Si estoy equivocado en eso, entonces necesitaremos usar callback. Pero creo que puede haber otras personas en esta sala que podrían responder eso por mí. Genial. Bien, más sobre eso.

¿Has probado el nuevo compilador de React para minimizar los re-renderizados? Y si es así, ¿has tenido algún resultado? He hecho una revisión rápida sobre esto. Y creo que hará algunas mejoras. Pero supongo que hemos pasado bastante tiempo, ya sabes, haciendo este tipo de investigaciones. Así que el código, ya sabes, que estaba demostrando el problema, eso fue, eso nunca se lanzó realmente. Así que esto fue algo que, supongo, perfilamos antes de lanzar esta versión de React.

Tomemos un paso atrás de estos temas técnicos profundos por un momento. Quiero preguntarte sobre tu día a día. ¿Cuánto de tu trabajo es construir características de AG Grid versus adaptarlo o hacerlo funcionar con frameworks? Eso depende mucho de las tareas en las que estamos trabajando. Así que, como cuando estaba mirando React o apoyando React 19, entonces supongo que todo mi día se pasaba en, bueno, ¿cómo nos aseguramos de que somos compatibles? Así que como ese cambio donde el modo estricto ahora estaba llamando doblemente en React 19, estos callbacks de ref. Así que eso fue algo que tuve que validar y asegurarme de que todo lo que hacíamos en esos callbacks lo pudiéramos limpiar y volver, lo cual creo que es algo bueno que al final React haya parcheado ese agujero, porque entonces te obliga a asegurarte de que estás limpiando todo y haciéndolo todo puro. Pero en otros momentos, ya sabes, en este momento, estamos trabajando en hacer que AG Grid sea realmente tree shakable. Así que he estado mirando archivos minificados. ¿Cómo hacemos, si renombramos esto o si hacemos esto una función independiente, cómo impacta eso en lo que termina en el bundle? Así que sí, se trata mucho de la tarea en la que estamos trabajando.

Suena emocionante. Es bueno, sí. Dando un paso aún más atrás, ¿cómo sabes si necesitas, dicen que es, supongo que necesitas AG grid? ¿Cómo sabes si necesitas AG grid? Bueno, quiero decir, lo más fácil es simplemente comenzar a usarlo. Sabes, puede darte muy simplemente una cuadrícula de datos con muchas características, ordenación, filtrado, todas las cosas listas para usar. E incluso si solo lo quieres como una tabla HTML simple, es un gran lugar para comenzar. Porque muchas personas han comenzado a construir su propia tabla y es muy simple comenzar a construir tu propia tabla. Pero muy rápidamente, el tamaño de los datos crece, necesitas agregar virtualización. Llega una solicitud de función, quiero cambiar el orden de las columnas. Y de repente todas estas cosas son muy costosas como desarrollador para hacerlas tú mismo. Así que diría que simplemente comienza con eso y crecerá con la complejidad de tu proyecto o simplemente satisfará tus necesidades y no tendrás que hacer mucho.

Eso suena como un plan razonable. Solo nos quedan preguntas técnicas. Así que dos minutos de esto. ¿Tienes algún consejo sobre cómo almacenar y trabajar con refs que necesitan estar disponibles a nivel de característica o aplicación? ¿A nivel de característica de aplicación? Como, por ejemplo, pasar un elemento a otra característica? No lo sé, es difícil saber sin saber cuáles son estas características. Pero supongo, sabes, que una vez que lo tienes como un ref, puedes pasarlo. Pero creo que tan pronto como, si estás haciendo eso demasiado, eso podría convertirse en un poco de lío de espagueti. Así que creo que quieres tener cuidado, pero dependería exactamente de lo que estás tratando de lograr. No sé si, tal vez puedan venir y hablar conmigo después y desarrollarlo un poco más. Si tienes algunas preguntas técnicas muy profundas, algo muy específico para la arquitectura de tu aplicación, quizás hablar con Stephen después de esto sería el siguiente paso correcto para ti.

Pero hablando de espagueti, ¿qué tal usar Redux para gestionar el estado? Parece que es bastante complicado y Redux podría ser útil. Así que tenemos una, supongo una implementación en JavaScript puro del estado de Agigrid. Y eso no está usando ninguna biblioteca. Y una de las grandes cosas de las que estamos orgullosos con Agigrid es que no hay dependencias externas, lo que lo hace mucho más fácil desde un propósito de seguridad para que la gente diga, bueno, solo voy a usar Agigrid, y también, no dependemos de interrupciones y cualquier otra cosa. Así que sí, como principio, probablemente no introduciríamos Redux para resolver esto. Parece razonable. No creo que tengamos suficiente tiempo para responder a ninguna de las siguientes preguntas. Así que voy a decir, para cualquiera más que quiera encontrar a Stephen después, esto, hay un conjunto completo de cosas buenas que puedes preguntarle. Stephen, gracias de nuevo. Démosle una ronda más de aplausos. Gracias. Gracias.