How React Compiler Performs on Real Code

Gracias por la introducción. Como se mencionó, mi nombre es Nadia. Permítanme comenzar presentándome rápidamente y hablando un poco sobre mí. He sido desarrolladora durante mucho tiempo ya. Trabajé para una pequeña startup en algún momento. Trabajé para Atlassian durante algunos años en un producto que algunos de ustedes probablemente conocen y probablemente aman llamado JIRM. Soy un poco perezosa y también me encanta viajar. Así que hace unos años, me mudé de Australia a Austria solo porque es más fácil de deletrear. Soy un poco nerd y uno de mis pasatiempos nerds es investigar cómo funcionan las cosas y luego escribir los resultados. Pasé los últimos años investigando todo lo que pude sobre rendimiento, sobre re-renderizados y React. Escribí un montón de artículos sobre este tema, hice videos en YouTube, incluso publiqué un libro, la mitad del cual está dedicado al tema de los re-renderizados, la memoización y cómo controlarlos. Y durante esos años seguí viendo visitantes del futuro probablemente que amablemente informaban a todos a su alrededor que la memoización ya no es necesaria debido a React forget, actualmente conocido como el compilador de React. Este abril, nuestra línea de tiempo finalmente se puso al día con la de ellos. El equipo de React lanzó el compilador al público y, por supuesto, tuve que probarlo y ver el futuro por mí misma. Así que probé el compilador en algunos ejemplos sintéticos, lo ejecuté en algunas aplicaciones reales, medí cómo funciona y qué hace. Por supuesto, lo escribí y ahora estoy feliz de compartir con ustedes cómo realmente se ve el futuro. Así que de esto se trata la charla.

compartir con ustedes cómo realmente se ve el futuro. Así que de esto se trata la charla. ¿Cuál es el problema que el compilador resuelve?

¿Tiene algún inconveniente? ¿Cómo se desempeña en ejemplos sintéticos y cómo se desempeña en código de la vida real? Comencemos con el problema. Entonces, ¿qué exactamente estamos tratando de resolver aquí? Aquí está nuestra hermosa interfaz de usuario, es realmente agradable. Cuando llega alguna nueva información allí, queremos actualizarla. Para hacer esto en React, activamos lo que se conoce como un re-renderizado. Los re-renderizados en React son en cascada, como probablemente saben. Cada vez que se activa un re-renderizado de un componente, activa un re-renderizado de cada componente dentro y luego cada componente dentro de este componente hasta que se alcanza el final del árbol.

Si esos re-renderizados posteriores afectan a algún componente realmente pesado, nuestra aplicación se vuelve lenta. Así que eso podría causar problemas de rendimiento. Para solucionar esto, necesitamos detener esta cadena de re-renderizados. Una forma de hacerlo en React es decirle a este componente que no cambia y que puede omitir re-renderizados y re-renderizado de cada componente dentro. Y por supuesto, como siempre en React, hay múltiples formas de hacerlo, pero una de ellas es la memoización. La memoización comienza con React memo, un archivo o el componente dado por el equipo de React. Envuelve nuestro componente original y luego se renderiza en su lugar. Ahora, cuando React llega a este componente en el árbol, se detendrá y verificará si sus props han cambiado. Si ninguna de las props cambió, entonces los re-renderizados se detendrán.

Si incluso una de las props cambia, React continuará con los re-renderizados como si no hubiera ocurrido memoización. Eso significa que para que el memo funcione correctamente, necesitamos asegurarnos de que cada prop en este componente sea exactamente la misma entre los re-renderizados, de lo contrario, simplemente no funcionará. Para valores primitivos, es fácil. No necesitamos hacer nada más que no cambiarlos. Para objetos, arreglos y funciones, sin embargo, necesitan algo de ayuda. React utiliza la igualdad referencial para verificar cualquier cosa entre re-renderizados. Y si declaramos esos valores no primitivos dentro del componente como lo hice aquí, se recrearán en cada re-renderizado. La referencia a ellos cambiará y la memoización no funcionará. Para solucionar esto, tenemos dos hooks, useMemo y useCallback. Colocaremos arreglos y objetos en useMemo, funciones en useCallback, y luego esos hooks preservarán una referencia a los valores entre los re-renderizados. Y la próxima vez que ocurra un re-renderizado aquí en el padre, el componente muy lento no se re-renderizará. Lo siento.

Esta es una explicación muy simplificada, pero como pueden ver, en realidad ya es bastante complicada. Así que cualquiera que haya usado esos hooks en la vida real sabe lo difícil que es rastrear esas referencias cambiantes y lo rápido que nuestras hermosas aplicaciones se convierten en un lío incomprensible e inutilizable de useMemo y useCallbacks. Así que resolver esta situación es la principal promesa del React Compiler.

El compilador es una herramienta que nos ha dado el equipo de React. Se conecta a nuestro sistema de construcción, toma el código original del componente y luego intenta convertirlo en código donde los componentes, las props y las dependencias de los hooks están memoizados por defecto. El resultado final es como si nuestro código normal de React se comportara como si todo estuviera envuelto en memoUse, memoUseCallback, lo cual ya es muy genial. Pero en realidad no hace esto. No envuelve las cosas ciegamente. Es mucho más inteligente que eso.

Por ejemplo, algo tan simple como esto se transformará en esto. Noten cómo onClick se almacena en caché en la parte inferior, pero el objeto data no está realmente almacenado en caché. Simplemente se movió dentro de la declaración if. Sin embargo, si hago referencia a este data dentro de onClick, el compilador entiende esto y reorganiza el código para que suene así. La mecánica de todo esto es absolutamente fascinante. Sin embargo, en este caso, estoy más interesado en las aplicaciones prácticas de este milagro de la ingeniería.

Así que más específicamente, quiero saber si nuestras expectativas del compilador coinciden con la realidad. Y tres preguntas principales surgen inmediatamente para casi todos. La primera es, ¿qué pasa con el rendimiento de carga inicial? Uno de los grandes argumentos en contra de memoizar todo por defecto siempre ha sido que puede afectar negativamente la carga inicial, porque React necesita hacer muchas más cosas de antemano donde todo está memoizado. La segunda es, ¿realmente tendrá un impacto positivo? ¿Cuánto problema representan realmente los re-renderizados? Y la tercera es, JavaScript es notorio por ser fluido y ambiguo. ¿Es el compilador lo suficientemente inteligente como para captar realmente absolutamente todo? ¿Es cierto que nunca más tendremos que pensar en la memorización y los re-renderizados? Antes de responder a esas preguntas, revisemos rápidamente el compilador en algunos ejemplos sintéticos. Tal vez, quién sabe, tal vez no funcione en absoluto.

Así que nuestro primer ejemplo, tenemos un componente con un diálogo, un estado para este diálogo y un botón que puede abrirlo. Y un componente muy lento en algún lugar debajo. Así que digamos que tarda cinco milisegundos en re-renderizarse. El comportamiento normal de React aquí sería re-renderizar todo, incluido el componente muy lento cuando el estado cambia. Y como resultado, el diálogo aparece con un retraso debido al componente lento. Si quisiera solucionarlo con memoización, tendría que hacer esto. Simplemente envolverlo en el React memo. Vamos a deshacernos de él y habilitar el compilador para este código y ver qué sucederá. En las herramientas de desarrollo, veo el mágico memo apareciendo por todas partes, las cosas azules.

En las herramientas de desarrollo, veo el mágico memo apareciendo por todas partes, las cosas azules. Eso significa que los componentes están optimizados por el compilador. Y ahora todo lo que necesito hacer es simplemente poner el logger dentro del componente muy lento e intentar activar el diálogo. Como pueden ver, solo el botón que renderiza, el diálogo, bueno, el diálogo aparece instantáneamente. Si un componente lento no se re-renderiza.

Así que esa es la primera victoria para el compilador. Ahora hagámoslo un poco más complicado y agreguemos algunas props al componente muy lento. Algo estándar, un objeto y una función. Así que si quisiera memorizarlo manualmente, este sería el trío clásico. Use memo, use callback, y memo en sí mismo. Vamos a deshacernos de él y aplicar el compilador al código. El resultado final, exactamente el mismo. Solo el botón se re-renderiza. El componente lento no se re-renderiza. El diálogo aparece instantáneamente. Estoy sumando otra victoria al compilador. Buen trabajo.

Me encanta. Tercero, y este es el divertido. Probemos algo aún más complicado antes de ir a una aplicación real. ¿Y si el componente muy lento acepta children? De inmediato, piensa cómo lo memorizarías. Te daré un segundo mientras pienso. ¿Quién piensa que debería ser esto? Levanten la mano. ¿Alguien? Genial. Gente muy, muy inteligente aquí. Porque sí, esto es incorrecto. Los children aquí no son más que azúcar sintáctica para una prop llamada children. Child memo es exactamente lo mismo que azúcar sintáctica para un objeto que se ve así, que hace referencia al componente child memo. Así que lo que tenemos aquí es una prop no memorizada en un componente memorizado. Componente muy lento, la memorización no funcionará, y se re-renderizará con cada cambio de estado. Para memorizarlo correctamente, necesitamos hacer esto.

Este patrón es el más contraintuitivo en React, e incluso los desarrolladores más senior a menudo lo interpretan mal. Sin embargo, ¿qué pasará con el compilador? ¿Puede manejarlo? Y la misma historia de antes. El compilador hace un muy buen trabajo. El diálogo aparece instantáneamente. No ocurren re-renderizados lentos. Otra victoria para el compilador.

Ahora a lo bueno. Ejemplos pequeños como ese son fáciles, pero quiero probarlo en una aplicación real. La aplicación real se ve así. Es una aplicación en la que he estado trabajando durante unos meses. Es completamente nueva. He scriptificado completamente con TypeScript, sin código heredado, solo hooks, y todo es mejor práctica, más o menos, porque soy un poco perezosa. La aplicación tiene algunas páginas. En total, tiene alrededor de 15,000 líneas de código. No es la aplicación más grande, pero creo que es lo suficientemente buena para una prueba adecuada. Antes de activar el compilador, ejecuto una verificación de salud y reglas de ESLint proporcionadas por el equipo de React. Esos son los resultados de la verificación de salud. No hay bibliotecas incompatibles, y cero violaciones de ESLint. Y finalmente, no he hecho ninguna optimización de rendimiento allí todavía, exactamente para poder probar el compilador para esta masterclass. La aplicación está tan preparada para el compilador de React como sea posible.

Condiciones de prueba. Usé Lighthouse para medir la carga inicial y el rendimiento de las interacciones. Todas las mediciones son cinco veces, así que en realidad les estoy mostrando el promedio de esas. Todas las mediciones se ejecutan en la compilación de producción en el modo móvil de Lighthouse, donde la CPU se ralentiza cuatro veces. Bien, así que la primera pregunta a responder, cómo afecta el compilador a la carga inicial. La primera página a medir es la página de inicio inicial. Es hermosa y en realidad bastante larga. Antes del compilador, los resultados eran así. Casi todo está en verde, excepto por una cosa roja. Lo arreglaré más tarde.

Ahora con el compilador, tengo muchos memos, eso significa que el compilador está funcionando, y aquí están las estadísticas. No está tan mal. Lo ejecuté en algunas páginas más solo para asegurarme, y los resultados fueron más o menos los mismos. Así que algunos de los números suben un poco, algunos de ellos bajan un poco. Nada drástico. Así que creo que puedo añadir otro punto al compilador y responder la primera pregunta, el compilador parece tener un impacto muy mínimo en el rendimiento de carga inicial. Así que eso es bueno.

No empeora las cosas. Segunda pregunta, ¿cuánto impacto tendrá en el rendimiento de las interacciones? Para esto, uso esta página. La aplicación es en realidad una muestra de una biblioteca de componentes de UI. Aquí vemos una vista previa de un componente muy grande, en realidad toda la página de configuración, y allí tengo un interruptor de modo oscuro. Como puedes ver, todo se vuelve a renderizar cuando cambio entre el modo claro y oscuro. Antes del compilador, los números se veían así, lo cual es un poco ouch, es un poco rojo. Activé el compilador y wow, eso es muy impresionante, y en realidad es demasiado bueno para ser verdad para mí porque soy una persona muy suspicaz. ¿Cómo exactamente sucedió eso? No soy la peor desarrolladora del mundo, créeme. Así que sí, necesito investigar esto. La respuesta está aquí.

Este es el código para toda esta página. Lo que renderiza la vista previa de los grandes componentes es esto. La vista previa se envía como una cadena, toda la página aquí es solo componentes realmente pequeños. Literalmente tengo aquí el ejemplo sintético de antes, donde tenemos un componente muy lento con algunos props menores. Así que añadiré otro punto al compilador. Es muy genial que haya podido captarlo, pero también siento un poco que está haciendo trampa porque situaciones claras como esta son bastante raras en la vida real. Así que en la vida real, tendremos un montón de componentes pequeños y el trabajo para el compilador será mucho más difícil. La siguiente página está más cerca de la vida real. Vamos a echar un vistazo. Tengo un encabezado aquí con algunas cosas, pie de página y una larga lista de tarjetas en el medio. El filtro rápido en la parte superior controla qué tarjetas se muestran, y como has visto, cuando hago clic en la casilla de verificación, por ejemplo, todo se vuelve a renderizar. Así que sin memorización, toda la página se vuelve a renderizar, todas las tarjetas se vuelven a renderizar.

Las estadísticas para este se ven así. Está más o menos bien, está en verde, pero hay algo de espacio para mejorar. Habilitar el compilador y verificar los números es bueno, pero en realidad es más creíble para mí. Pero también, es muy interesante porque en realidad esperaba que fuera mejor porque esta lista es muy larga, y si todas las re-renderizaciones en esta lista fueran eliminadas, agregar solo unas pocas tarjetas nuevas para la casilla de verificación debería haber sido realmente instantáneo. Así que investiguemos qué está pasando aquí. Y lo que está pasando es que la lista en realidad sigue volviendo a renderizarse, incluso con el compilador habilitado. Eso no es tan bueno.

Bien, ¿qué está pasando con el código? Eso no es tan bueno. Bien, ¿qué está pasando con el código? Los primeros, nada criminal. Solo tengo un array de elementos, un map sobre el array, y un componente de tarjeta de renderizado. Incluso tengo la clave correcta aquí, así que no hay props arbitrarios, todo viene del array de datos. Así que investiguemos. Lo primero que hago al depurar problemas del compilador es re-implementar la memorización manualmente con las herramientas clásicas. En este caso, todo lo que necesito hacer es simplemente envolver la tarjeta en el react.memo. Y si el código es bueno, la tarjeta existente debería dejar de volver a renderizarse, y eso significaría que el compilador falló en sus componentes por alguna razón. Hice eso, y esto no sucedió. Eso significa que en realidad no es culpa del compilador. Algo está profundamente mal con el código en sí.

Me pregunto si alguien puede adivinar, porque el código es el más estándar que puedes ver en React. Bien, resolvámoslo. Como ya sabemos, si incluso un solo prop en el componente memorizado cambia, la memorización no funcionará, y las re-renderizaciones ocurrirán. Así que probablemente algo está mal con los props aquí. Todos ellos son primitivos excepto por este. Es un objeto con dos cadenas dentro. Así que tiene que ser su culpa. Pero también es un poco extraño porque no es como si lo estuviera recreando dentro del componente cada vez. Es solo los datos que vienen de un array que viene de un React query. ¿Debería culpar entonces a Dominic y React query? Vamos a echar un vistazo a este código. Este es el código que obtiene los datos. Todos conocemos React query ahora.

Es una biblioteca hermosa. Me encanta. Simplifica la obtención de datos y el almacenamiento en caché. Así que tenemos una clave para identificar la entrada de caché, y tenemos una función asíncrona que devuelve algunos datos para esta clave. Usualmente, es solo un fetch o alguna variación de fetch. Si se llama con la misma clave, devuelve los datos que ya tiene sin hacer un fetch de nuevo. Entonces, ¿qué está pasando aquí en mi caso? Tengo una clave dinámica. Depende de los filtros seleccionados. Y tengo una función de fetch que devuelve algunos datos.

Cuando solo se selecciona el botón en los filtros rápidos, la clave es esta. La biblioteca que devuelve un array que está asociado con esta clave. Cuando activo la casilla de verificación, la clave es esta. La biblioteca devuelve un conjunto completamente diferente de datos que está asociado con esta clave. No los fusiona para preservar la referencia a los objetos internos porque ¿cómo sabría hacerlo? Y nunca le dije que lo hiciera. Así que no puedo culpar a React query por esto, desafortunadamente. Todo esto es mi culpa. React query hace exactamente lo que debería hacer. Nadie a quien culpar, pero como resultado, tengo un array diferente con diferentes referencias renderizado en la pantalla que resulta tener los mismos datos en su mayoría.

Y una parte de estos datos es un objeto que se pasa a un prop a un componente memorizado. La forma más fácil de solucionarlo, para arreglar la memorización aquí, es simplemente expandir este objeto y convertirlo en props primitivas. Suena así. Así que el componente memorizado recibe solo valores primitivos y esos no cambian realmente. Así que un poco de refactorización y no más renderizaciones innecesarias. Bien, así que no soy el peor desarrollador del mundo. Asegurémonos de que realmente valió la pena y midámoslo. Así que esto fue antes y después del compilador. Ahora, la última medición después de la corrección manual. Siento que es una situación de mic drop. Los humanos siguen siendo mejores que los robots. Nunca dominarán el mundo.

Me daré una victoria a mí misma esta vez. Bien, eso fue sobre las interacciones. Creo que es seguro decir que el impacto del compilador es notable pero varía de una página a otra y los humanos todavía son mejores si realmente lo intentan.

Pregunta final. ¿Es el compilador lo suficientemente inteligente como para capturar absolutamente todo? Ya vemos que la respuesta probablemente es no. Pero para probarlo un poco más, recopilé una lista de re-renders notables en mi aplicación y verifiqué cuántos re-renders aún están presentes después de habilitar el compilador. Tenía algo así como nueve de ellos. Cosas como que todo el dibujo se vuelve a renderizar cuando cambian las pestañas. El resultado final fue este. Tuve dos casos donde absolutamente cada re-render fue resuelto, dos casos donde ninguno de ellos fue resuelto y cinco casos donde fue como en la situación anterior. Casi todos ellos, pero a veces no.

Los casos donde nada fue solucionado fueron los más interesantes porque el compilador se rindió en todo el componente debido a esta línea y solo esta línea. Ni siquiera usé los datos filtrados, solo agregué esta línea y es simplemente ups, no puedo hacerlo. Y el problema aquí es que Fuse es una biblioteca externa que hace búsquedas por ti. Así que la razón más probable aquí es que esta biblioteca simplemente está haciendo algo profundamente incompatible con el compilador, desafortunadamente. Y hablando de las bibliotecas externas, hace solo unos días el equipo de React confirmó que las bibliotecas externas no serán transpiladas por el compilador. Así que no esperes milagros si consumes alguna biblioteca externa.

Así que voy a ser cruel, lo siento. Voy a quitarle un premio al compilador por esto. Porque la respuesta a si el compilador puede capturar absolutamente cada re-render singular es lamentablemente no. Porque siempre habrá algunas bibliotecas externas que hacen cosas realmente extrañas o simplemente son incompatibles con la memorización o habrá algún código heredado que nuevamente hace cosas realmente extrañas que el compilador no sabe cómo procesar. O el código que tenía, que no es exactamente incorrecto pero simplemente no está ajustado para la memorización. Así que recapitulemos rápidamente lo que estábamos investigando y cómo el compilador lo manejó. Rendimiento inicial, verificado. Sin impacto, sin impacto negativo. Rendimiento de carga inicial, también diría verificado. Interacciones, rendimiento de interacciones, verificado. Vi buenas mejoras allí. Algunas de ellas fueron realmente buenas, algunas de ellas solo un poco pero aún así realmente buenas. ¿Puede capturar todos los re-renders? No y probablemente nunca lo hará.

Entonces la pregunta más importante de este año, ¿podemos olvidarnos de la memorización pronto? ¿Significa la diapositiva anterior que la respuesta a esta pregunta es no? No necesariamente porque realmente depende. Si el rendimiento de tu aplicación no es lo más importante del mundo para ti o tal vez está bien pero podría mejorarse pero no tengo tiempo para preocuparme, entonces habilitar el compilador probablemente lo hará lo suficientemente bueno a un costo muy bajo. La definición de lo suficientemente bueno y bajo costo, por supuesto, dependerá de ti pero sospecho que para la mayoría de las personas encender el compilador y olvidarse de la memorización y todos esos hooks será suficiente. Sin embargo, si lo suficientemente bueno no es tan bueno para ti o necesitas por alguna razón exprimir cada milisegundo de tu aplicación, serás bienvenido de vuelta a la memorización manual. Para ti la respuesta será no. No puedes olvidarte de ello. Tendrías que saber todo lo que sabemos sobre memorización ahora. Además, además de eso, tendrías que saber qué es el compilador y qué hace y cómo. Así que tu trabajo se volverá un poco más difícil pero creo que habrá muy muy pocos de ustedes que realmente lo necesitarán, así que eso mejorará tu seguridad laboral diría yo a largo plazo.

Así que también es un buen resultado positivo para ti. Espero que esto haya sido lo suficientemente bueno para esta presentación. Si quieres leer más sobre memorización y re-renders y todo, aquí están los enlaces. Si quieres ver la versión muy muy temprana de los componentes en los que estoy trabajando, puedes hacerlo aquí. Está muy en progreso, así que por favor no juzgues demasiado. Y si quieres pegatinas realmente geniales con temática de gatos, encuéntrame después de la charla. Tengo bastantes de ellas. Gracias. Y ese es el final.

Bueno, déjame sacar mis pequeñas preguntas aquí. Recuerda que puedes hacer preguntas en slide.do y vamos a sumergirnos directamente en el compilador. Hay un par de preguntas aquí. Así que esta dice qué optimizaciones manuales funcionan mejor con un compilador en un gran proyecto de React y algún consejo para encontrar cuellos de botella? Así que las optimizaciones manuales funcionan mejor moviendo el estado hacia abajo y aislándolo tanto como sea posible para que nunca tengas componentes que manejen mucho estado. También extrayendo el estado en lugar de pasar a través de props a una biblioteca externa como algo como Sustan por ejemplo y luego memorizando los selectores. Sí, tenemos la cosa de Toka. Sí. Era sobre encontrar cuellos de botella. La cosa del estado es buena. ¿Crees que la gente o los desarrolladores van a empezar a cambiar su comportamiento basado en lo que el compilador es bueno? Veremos supongo. Porque ese ejemplo de lista que hiciste, eso fue solo el pequeño componente. Sí.

Puedo ver a la gente intentándolo. Así que lo que me da un poco de miedo es que la gente se relaje y diga oh, el compilador manejará todo. Así que podría llevar a un código desordenado a largo plazo. Pero confío en el grupo aquí porque en realidad nadie levantó la mano sobre el problema de la memorización. Estoy muy impresionada. Buen trabajo. Sí.

¿Hay alguna manera de si el compilador no lo hace por alguna razón forzar la memorización? Sí, usamos los hooks y React memo. Solo memorización manual como en los viejos tiempos. Como en los viejos tiempos. Vintage. Tan adorable. Muy bien.

¿Cómo funciona el sistema de re-renderizado cuando los props no cambian pero un proveedor de context sí? Context si estamos hablando de React context. Hasta hace muy poco simplemente forzaría el re-renderizado en absolutamente todo. Incluso si no usas los datos. Pero creo que hubo alguna charla del equipo de React para introducir la funcionalidad de selector stub pero no estoy tan segura. Pero actualmente simplemente volverá a renderizar todo lo que usa context. Interesante.

¿Puedes pensar en alguna razón para no usar el compilador de React? Para no usar el compilador de React. Podría ser un poco aterrador en las aplicaciones muy grandes y muy antiguas porque quién sabe cuáles serán los efectos de esta memorización manual. Así que para esas aplicaciones solo diría habilítalo archivo por archivo o carpeta por carpeta y luego haz muchas pruebas. Tómalo con calma. Sí, tómalo con calma y prueba cosas. Me gusta ese consejo en realidad. Es muy sensato. Este es un gran consejo. Vamos a salirnos un poco del compilador de React por un segundo. Les encantaron tus diapositivas. Son muy geniales.

Muchos buenos gatos. ¿Cómo los haces? Mucha práctica. Son increíbles. Buen trabajo. Con software ¿usas Keynote? Keynote. Keynote y Magic Move para la mayoría de ellos. Sí, Magic Move. ¿Quién no ama Magic Move? El mismo Steve Jobs.

Veamos. ¿Qué más tiene la gente? ¿El compilador en tus exploraciones alguna vez ha intentado arreglar algo y realmente introdujo un comportamiento negativo o un error? No para mí. Probablemente haya una posibilidad. Vi a personas diciendo que algo sucedió, pero es muy, muy raro según mi entendimiento. Y funciona para como Instagram y Facebook y algunas aplicaciones más grandes, así que estoy segura de que encontraron casi todo lo que puede ser. Sí, bueno, eso esperaría.

Y luego, cuando habilitas el compilador en tu aplicación donde ya has usado previamente Callback o Memo, ¿es una mala práctica seguir teniendo esas optimizaciones? ¿Tenemos que eliminarlas para usar el compilador? Hasta donde recuerdo, no tienes que hacerlo. Simplemente las usará o las convertirá en código. Así que no tienes que recordarlas. Pero probablemente tengamos un equipo de miembros de React que recuerden aquí. Así que asegúrate de ir a preguntarles las realmente sí, realmente, realmente preguntas profundas. Lo siento, solo te estoy dejando cosas. No tenemos mucho tiempo, así que en realidad voy a hacerte solo una pregunta más, que es ¿cuál es tu proceso para hacer todas estas exploraciones profundas que hiciste para tu libro y ahora para esta charla? ¿Tienes como un sistema de investigación? ¿Miras mucho el código fuente? ¿Lo ejecutas más o lo lees más? Esa es como una respuesta de media hora.

TLDR. TLDR. Así que generalmente solo tengo una idea que surge de hacer cosas regulares. Luego empiezo a explorar esta idea. Comienzo a escribir ejemplos para ella. Luego empiezo a escribir el artículo y luego estoy desechando todos los ejemplos porque en realidad no coinciden con el artículo y los reescribo completamente desde cero. Pero luego, cómo los reescribo, generalmente descubro algunas cosas nuevas, así que tengo que reescribir el artículo nuevamente. Así que es como iterativo. Es básicamente ágil. Sí, básicamente ágil.

¿Recordarás a todos dónde pueden encontrarte en línea en Twitter o LinkedIn? Advanced Dev. A-Dev Nadia. Muchas gracias, Nadia, por esa charla.