Una Guía para el Renderizado del Compilador de React

Muy bien. Buenos días, Ámsterdam. Mi nombre es Marc Erickson, y estoy muy emocionado de compartir con ustedes una guía sobre la representación del compilador de React. Un par de cosas rápidas sobre mí. Soy un ingeniero de viaje en el tiempo senior en Replay, donde construimos un depurador de viaje en el tiempo para tanto humanos como agentes. Responderé preguntas en cualquier lugar donde haya un cuadro de texto en Internet. Ayudo a moderar las comunidades de React. Recolecto enlaces interesantes y hablo sobre ellos en lugares como el podcast This Month in React. Escribo publicaciones de blog extremadamente largas. Recientemente escribí un artículo sobre mi propia experiencia emocional usando IA, así como mi flujo de trabajo, y soy un mantenedor de Redux. Hace casi exactamente diez años que he estado trabajando en Redux. Pero también la mayoría de la gente me conoce como ese tipo con el avatar de los Simpsons, que en realidad ahora está ligeramente desactualizado. Me hice LASIK en enero.

¿Por qué estamos hablando de la representación de React hoy? Soy un firme creyente de que es importante conocer los fundamentos de las herramientas que estamos usando, y eso es aún más cierto en una era de IA. Incluso hoy, veo a muchas personas con conceptos erróneos sobre cómo React realmente funciona. Cuando hablamos del compilador de React, voltea parte de ese comportamiento predeterminado al revés. Necesitas asegurarte de entender los fundamentos primero. Y esto es realmente ciencia, no magia. Así que los objetivos para hoy, pasaremos algún tiempo revisando algunos fundamentos del comportamiento de React, vamos a ver las opciones que tenemos disponibles para optimizar el rendimiento de React, veremos lo que hace el compilador y cómo se ve la salida, y luego terminaremos hablando sobre cómo cambia nuestro modelo mental de cómo usar React. Las diapositivas están en mi blog, blog.isquaredsoftware.com, y tendré el enlace allí nuevamente al final.

De vuelta al principio. ¿Qué es la representación? La representación es el proceso de React preguntando a tus componentes, ¿cómo quieres que se vea la interfaz de usuario en este momento? Normalmente, la salida de la representación se basa en los props actuales y el estado de ese componente. Cuando escribimos componentes, escribimos esta sintaxis de corchetes angulares JSX que hemos visto y todos conocemos y amamos, y cuando escribimos la sintaxis JSX en nuestro código, en tiempo de compilación, eso se convierte en llamadas a create element, y luego en tiempo de ejecución, tu componente se ejecuta, llama a create element, y devuelve estos objetos de elemento que tienen el componente y sus props y los hijos. Si alguna vez has escuchado el término DOM virtual, eso realmente solo describe estos objetos de elemento. Así que durante una representación, React recorre todos tus componentes, recopila todos los objetos de elemento en un árbol, y luego compara los árboles de elementos antiguos y nuevos para averiguar, ¿estás pidiendo algo diferente en la interfaz de usuario esta vez? Ahora, un punto muy, muy importante, si hay algo que recuerdes, por favor recuerda esta diapositiva justo aquí. El comportamiento predeterminado de React es que cuando representas en un componente, llamas a set state, React seguirá recursando a través de todos los hijos debajo de eso. Así que si llamo a set state en el componente de la aplicación allá arriba, continuará a través de los cuatro hijos debajo de eso. Si llamo a set state en el componente de inspiración, también representará los dos hijos debajo de eso. Sigue bajando a través de todos los hijos debajo. Ahora, cuando representamos, esto no siempre significa que hay una actualización en el DOM.

React originalmente habló sobre la representación como volver a dibujar toda tu página, pero en realidad, ¿hubo alguna diferencia? ¿Hay algún cambio solicitado en la interfaz de usuario? Entonces es posible representar un componente, hacer que solicite el mismo resultado que la última vez, y si lo piensas, entonces eso es un tipo de esfuerzo desperdiciado. Pasamos por el proceso de ejecutar el componente y generar los elementos y en realidad no se necesitaba cambiar nada, por lo que podemos pensar en esos como representaciones desperdiciadas, y generalmente eso es si hay los mismos props en el mismo estado, entonces estamos pidiendo los mismos hijos que la última vez. Pero en general, la representación no es algo malo. Es cómo React sabe si hay algo que necesitamos actualizar.

Ahora, React tiene una serie de reglas que se supone que debes seguir. No se supone que debamos mutar valores existentes como props y estado, no deberías estar generando valores aleatorios mientras representas, y especialmente nunca uses esos como claves. Está bien mutar valores que creaste durante el proceso de representación. Un console log es técnicamente un efecto secundario, pero está bien, eso no rompe nada. Hay momentos en los que puedes inicializar perezosamente un objeto ref. No deberías estar activando solicitudes mientras representas, a menos que estés usando suspense, y en teoría puedes llamar a set state mientras representas, pero solo si es condicional. Hay algunas cosas que debes tener en cuenta mientras representas.

Entonces, ¿cómo optimizamos realmente el rendimiento? React nos da algunas herramientas para hacer eso, y la forma principal de optimizar es diciendo si los props de este componente no han cambiado, no lo representes. Y si omitimos este componente, eso significa que también omitimos todos los hijos dentro de él. Así que la herramienta principal que React nos da es la función memo. Si alguna vez has escuchado el término componente de orden superior, solo significa que es un envoltorio alrededor del componente real que tienes. Así que memo es un componente de orden superior que automáticamente mira todos los props entrantes, y si ninguno de los props ha cambiado, omite este componente. Ahora hay otro truco muy poco conocido que está integrado en React que ha existido realmente desde el principio, pero nadie sabe que esto existe. Si estás representando un componente, y, como parte del resultado, incluyes la misma referencia de objeto de elemento exacta que tenías la última vez, React llegará a esa parte, y dirá este es el mismo elemento. Solo voy a omitir esto. Hay un par de maneras de hacer esto. Una es haciendo un use memo para memorizar la creación de algunos de los elementos, o si alguna vez has usado el prop children e incluido eso en el resultado, ese es el mismo elemento que la última vez. Y la forma en que me gusta pensar en esto es React.memo es el propio componente hijo diciendo, quiero ser optimizado. Solo vuelve a representarme si mis props cambian. Me gusta pensar en el truco de referencia de elemento como el componente padre diciendo si los inputs de este no han cambiado, no lo representes. Ahora, en esa nota, esta es una de las ideas erróneas más comunes que todavía he visto a lo largo de los años. La gente realmente desde el principio asumió que React solo vuelve a representar mis componentes cuando sus props cambian. No, no, ese no es el caso. Dije antes, cuando React representa, simplemente sigue de arriba a abajo desde donde hiciste un set state. La única vez que las referencias de props importan es si estás tratando de optimizarlo. Si tienes un React.memo, entonces los props importan.

De lo contrario, React dice siguiente componente, siguiente componente, y sigue adelante. Entonces esto plantea un conjunto muy común de preguntas que es ¿por qué no envolvemos todo en React.memo? ¿Por qué React no funciona de esta manera desde el principio? ¿Deberíamos poner cada controlador de clic en un use callback, use memo, usar algo en todas partes?

Y si miraras los documentos de React, históricamente, el equipo de React ha dicho que no hagas esto, y hay algunas razones. Una es que simplemente agrega mucho código extra. Otra es que a veces, un componente podría siempre recibir nuevas referencias de props, y entonces estás haciendo comparaciones y verificaciones que nunca tendrán éxito, y es simplemente un esfuerzo desperdiciado. Así que históricamente, han dicho que no memorices todo, mira si tienes problemas de rendimiento en tu aplicación, encuentra componentes específicos que se beneficiarían, y luego envuelve solo esos específicos en memo.

Así que dije que esta era una charla sobre el compilador de React. ¿Qué hace el compilador de React? El compilador de React optimiza automáticamente todos tus componentes por ti, y, de hecho, si miras la página de documentos, específicamente dicen que lo hace por ti para que no tengas que pasar tiempo pensando en esto, y puedas concentrarte en solo escribir el código para tu aplicación. Entonces, ¿qué hace?

Tenemos un valor de usuario y una prop on-follow, formatea el nombre, y luego devuelve un poco de JSX. Entonces, si paso esto por el compilador, ¿cómo se ve esto? Oh. Oh querido, ¿qué pasó aquí? ¿Qué son todos estos signos de dólar? ¿Alguien derramó algo de jQuery aquí? ¿Qué es esto? He visto a algunas personas mirar la salida del compilador y entrar en pánico. En realidad, no es tan complicado.

Vamos a desglosarlo. Si miraras la forma en que el compilador reescribe tu componente, en realidad solo sigue escribiendo el mismo patrón una y otra vez. Así que aquí hay un ejemplo inventado de lo que está haciendo con algunos nombres de variables más legibles. Entonces, lo que hace es que mira todas las entradas para un cálculo específico, y mira un valor de caché, y dice, ¿ha cambiado alguno de estos valores de entrada desde la última vez que este componente se ejecutó? Si alguno de ellos cambió, entonces volverá a ejecutar el cálculo, y guarda tanto el resultado como las entradas.

De lo contrario, si ninguno de ellos cambió, simplemente podemos usar el resultado que calculamos la última vez. Espera, ¿por qué suena esto familiar? Oh, espera, eso es exactamente como lo que hace el hook used memo. Realmente todo esto es una serie de declaraciones if-else que son exactamente lo mismo que un used memo, solo que escrito de manera un poco más complicada. Es lo mismo. Así que el mismo ejemplo aquí, donde estamos calculando parte de la salida de JSX. Verificamos si el campo de nombre ha cambiado. Si lo ha hecho, recalculamos el elemento H2 y luego lo incluimos en el resultado, de lo contrario usamos el resultado guardado de la última vez. Nuevamente, podrías haber hecho esto tú mismo poniéndolo en un used memo. Ahora, en mi ejemplo, usé una variable llamada cache, y nombré campos como nombre resultado para hacerlo más legible.

En la salida real, el compilador está utilizando una variable con signo de dólar, y es un array, no un objeto. Así que estos, tengo mi ejemplo inventado a la izquierda, y luego tenemos la salida real en el lado derecho. Nuevamente, es lo mismo, solo estamos diciendo, aquí están las entradas anteriores, ¿ha cambiado alguna de ellas? Si es así, reutiliza el resultado.

¿Qué pasa con esa cosa de guion bajo C? ¿Qué es eso? Así que React 19 en realidad viene con un nuevo hook llamado use memo cache, y en realidad tienen un polyfill que hace que esto funcione para versiones anteriores de React, y realmente todo lo que es es un used memo que crea un array, y el compilador averigua qué tan grande necesita ser este array ¿Cuántos espacios y cuántos valores necesito guardar? Se lo pasa a un hook, el hook crea un array de ese tamaño, y ahora tiene todo el espacio que necesita para almacenar en caché los resultados. Así que para cuando hemos reescrito las primeras partes del componente, llegamos al final, va a ensamblar todos los valores para crear el resultado final, y nuevamente, tomamos algunas entradas más, en este caso las piezas del JSX que calculamos anteriormente, las ensamblamos en un resultado final, y devolvemos eso, así que nuevamente, es el mismo patrón if-else todo el camino hacia abajo.

Entonces, ¿cómo mejora esto realmente el rendimiento? Hace un par de cosas. Una es que si tienes lógica que podría ser costosa, solo se ejecutará cuando los inputs cambien, no cada vez que pase por el componente. También estamos ahorrando un poco de trabajo porque no necesariamente estamos recreando todos los elementos JSX cada vez, pero la gran ventaja es que hemos memorizado los elementos JSX. Solo los recreamos cuando los inputs cambian, y eso hace que la misma optimización de referencia de elementos entre en acción, y así React terminará omitiendo renderizar esos componentes hijos a menos que los datos hayan cambiado.

Entonces, ¿qué pasa con otros usos? ¿Qué pasa si tienes algún contexto? Es lo mismo. En este ejemplo, extraemos un par de valores del contexto, y React automáticamente verá que esos se están usando, escribirá la lógica de memorización if-else, y producirá los resultados. ¿Qué pasa si estás usando Redux o Zustan? Lo mismo, y de hecho, esto realmente hace una pequeña mejora. Aquí estoy escribiendo una función flecha en línea como el selector, y puedes hacer eso perfectamente bien con React Redux. Hace que la lógica interna diga, oh, espera, esta es una nueva referencia de función, déjame verificar los resultados. Y el compilador realmente ha guardado esa función flecha, por lo que solo se recrea cuando el prop category ID cambia. Así que una mejora muy, muy pequeña, pero, nuevamente, está mejorando las cosas.

Entonces, ¿qué pasa si tienes useMemo en tu componente, o qué pasa si estás usando contexto en tu componente? ¿Cómo mejora eso las cosas? El compilador realmente buscará useMemo y useCallback que hayas escrito y los reemplazará con su propia salida. Mismo resultado, pero tal vez funcione un poco mejor. Si tienes contexto en tu componente, no cambia cómo funciona el contexto. Si pongo un nuevo valor en el proveedor de contexto, cada componente que lea el contexto aún se volverá a renderizar. Pero el mayor problema con el contexto para el rendimiento es que pongo un nuevo valor en la parte superior, estos componentes lo leen, y luego todo lo que está debajo de esos se renderiza. Ahora, con el compilador, este componente lee el contexto, aún se vuelve a renderizar, pero los hijos solo se vuelven a renderizar si los datos realmente cambian. Así que no necesariamente se propaga todo el camino hacia abajo. ¿No dijimos que no se supone que debes mutar valores mientras renderizas? Técnicamente, esto está mutando el array, pero es el equipo de React, es el compilador, no lo sé. Supongo que está bien.

¿Cómo cambia esto la forma en que pensamos sobre React? Dije antes que es un error común pensar que mi componente solo se vuelve a renderizar cuando los props cambian. Con React de fábrica, eso no es cierto. Simplemente recurre hasta el final. Aquí es donde es importante entender el comportamiento predeterminado, porque el compilador de React lo invierte. Cuando instalas el compilador y lo ejecutas en tus componentes, ahora, por primera vez, tus componentes hijos realmente solo se vuelven a renderizar si sus props y entradas han cambiado. Eso sí cambia cómo pensamos sobre cómo estamos escribiendo nuestros componentes.

Entonces, ¿cómo enseñamos esto realmente? ¿Qué pasa si un desarrollador entra en una base de código que ya tiene el compilador instalado y no están viendo use memos y todo funciona automáticamente, y luego cambian a otro proyecto que no tiene el compilador instalado? Puedo ver algunos problemas de aprendizaje aquí donde se confunden, no entienden que el compilador está haciendo todo este trabajo extra por ellos, por lo que podrían tener algunas suposiciones incorrectas. Se remonta a los principios en los que creo firmemente, que es realmente importante que entendamos cómo funcionan nuestras herramientas y los fundamentos. Tuvimos este mismo problema con Redux. Usamos la biblioteca de actualización inmutable en Redux toolkit que te permite escribir código mutable, y tienes que recordar que esto solo funciona dentro de funciones como create slice.

Para mí, es un problema de educación. Dentro de nuestros documentos, expliqué muy claramente que tienes que entender la inmutabilidad en Redux, y el compilador está haciendo esta magia por ti. De la misma manera, creo que necesitas entender los fundamentos de cómo funciona el renderizado de React, y luego entender que el compilador cambia algunos de esos comportamientos. Muy bien. Creo que estoy, más o menos, a tiempo. Entonces, ¿dónde se encuentra el compilador de React hoy? Está disponible, alcanzó la versión 1.0 el otoño pasado, los documentos de React tienen una sección que habla sobre cómo configurarlo y cómo puedes configurarlo. Además, creo que hay algunas reglas de linting que te dirán si tienes componentes que rompen las reglas de React, para tu información, el compilador no optimizará estos, podrías querer actualizar esos componentes específicos. Hay un playground en línea, que, veamos si eso funciona. Hay un playground donde puedes intentar editar algunos componentes de forma interactiva y ver el resultado. Una nota sobre el compilador, el compilador en sí está originalmente escrito en TypeScript, y se entrega como un complemento de Babel, y desafortunadamente hemos pasado los últimos años cambiando nuestras herramientas de construcción para usar Rust y eliminando Babel, y hasta hace solo unos días, realmente tenías que volver a agregar Babel a tu paso de construcción para usar el compilador, lo que desafortunadamente ralentiza las cosas. El equipo de React ha pasado los últimos meses portando el compilador de React a Rust. Acaban de fusionar ese PR hace un par de días. Todavía hay algo de trabajo de integración que tiene que suceder para que funcione con el resto del ecosistema de herramientas de la cadena de JavaScript, pero eso debería acelerar las cosas. Y nuevamente, quiere ese nuevo hook que solo existe en React 19. Si estás usando React 17 o 18, hay un polyfill para ese hook para que pueda funcionar con esos también. Muy bien. Eso es toda la información oficial que tenía.

Rápido anuncio del trabajo del día. Mencioné anteriormente que trabajo en Replay, donde hemos construido un depurador de viaje en el tiempo para JavaScript, hacer una grabación de un error, y luego puedes investigarlo con poderes de viaje en el tiempo. Originalmente construimos herramientas de desarrollo de navegador con viaje en el tiempo incorporado para que los humanos puedan investigar. Desafortunadamente, resultó que a la gente realmente no le gusta pasar tiempo depurando. No sé por qué. Es divertido averiguar qué salió mal. Enviamos un MCP a principios de este año que permite a los agentes hacer gran parte de la investigación. He pasado un montón de tiempo mejorando nuestras herramientas MCP con análisis sobre renders de React y tiempos de rendimiento, incluso en construcciones de producción, así como herramientas que pueden decirte sobre la gestión del estado. Incluso publiqué un par de entradas de blog. Escribí una sobre cómo Replay encontró un error de React más rápido que Dan Abramov. Hemos construido herramientas geniales sobre el MCP. Enviamos una herramienta de QA que puede investigar sitios web, averiguar cómo los usuarios los usarían, encontrar automáticamente y reportar errores para ti, y tenemos una herramienta de agente de CI que puede grabar pruebas de playwright y Cypress e investigar pruebas fallidas y decirte qué se rompió en CI. Puedes verlas ahora en Replay IO o venir a preguntarme. Me encantaría contarte lo increíbles que son y cuánto tiempo te ahorrarán. Como siempre, tengo enlaces a muchas de estas cosas en las diapositivas de mi blog, y puedes encontrarlos allí. Muchas gracias.

Primero que todo, charla increíble. Y gracias a ustedes por sus preguntas que han estado llegando. Asegúrate de votar por las preguntas. Si ves una que también te parece interesante. E incluso si no llegamos a todas ellas, habrá la sesión de preguntas y respuestas en persona donde puedes ir y obtener un seguimiento. Así que comencemos con la primera, que me parece hilarante porque Dan Abramov es el nombre de la persona que la ha escrito, que es ¿qué impacto crees que tendrán las reescrituras en Rust del compilador de React? Observando las cosas, creo que ha habido dos o tres barreras diferentes para que la gente adopte el compilador de React. Una es que no está activado por defecto, y mucho de eso es que hay tantos diferentes frameworks de React y sistemas de construcción de React. Así que Next.js incluye una opción de compilador de React ya incorporada, pero si estás usando Tanstack, Start, Vite, RSPack, algo más, realmente tienes que instalar el plugin. Se necesita una elección para activarlo. Pero los otros dos problemas son que tienes que reintroducir Babel en el sistema de construcción, y hemos pasado los últimos años tratando de eliminar Babel, y luego he visto a muchas personas decir que agregar eso hace que sus tiempos de construcción sean drásticamente más lentos. Así que tengo la esperanza de que el puerto de Rust mejore la adopción al eliminar los dos últimos como problemas. Que si estás usando cualquier, ya sabes, V8 está integrado, que es el conjunto de herramientas OXC, que las herramientas de Rust se integrarán mejor con eso, por lo que no se necesita un plugin de Babel, y luego tanto la eliminación de un plugin de Babel como la lógica del compilador en Rust harán que se ejecute más rápido y eliminen eso como un problema. Así que todavía tienes que elegir usarlo, pero al menos, ups, el tiempo de construcción se triplicó no será una preocupación. No, eso tendría sentido.

Eso tiene mucho sentido. Tenemos otra pregunta. Esta es de anónimo. ¿Todavía hay un caso de uso para use memo? Y hablaste un poco sobre eso en tu charla, pero podrías... Algunos, sí. Uno es que el compilador buscará use memo y, ya sabes, lo colocará automáticamente para que, de alguna manera, podría actuar como una pista para el compilador de que sí, esto definitivamente debería ser memoizado. Pero con suerte no tendrás que pasar tanto tiempo escribiendo eso en tu propio código. Fue realmente interesante cuando hablaste sobre cómo va a haber mucho aprendizaje donde la gente no se da cuenta de que estas cosas están sucediendo bajo el capó. Siempre es realmente interesante ver eso como ingeniero y ver cómo eso cambia.

Una de las grandes cosas sobre el software es que podemos construir abstracciones. No tengo que pensar en C++ o Win32 o APIs de POSIX cuando estoy escribiendo JavaScript en un navegador, pero al menos necesito saber qué están haciendo mis bibliotecas y cómo funcionan, como el nivel justo debajo del código que estoy escribiendo. El siguiente tipo de pregunta lleva a mirar bajo el capó del compilador. Así que esta es cuando el compilador no puede analizar estáticamente un componente y se retira de la memoización y la optimización. ¿Cómo sabe un desarrollador que eso sucedió? ¿Cuál es la historia de depuración si hay tal vez un componente que se deja silenciosamente sin optimizar? Creo que aquí es donde el compilador o las reglas de lint impulsadas por el compilador te dirán... Harán un escaneo de tu base de código y te dirán qué componentes rompen las reglas de React. Por el contrario, hay una directiva que puedes agregar, que creo que es use no memo como una cadena. Simplemente dile específicamente, no intentes optimizar este componente. Sabemos que este componente tiene un problema, simplemente no intentes hacer eso. Pero generalmente usando las reglas de lint debería decirte en qué componentes se retiraría.

Me encanta que haya la capacidad de simplemente decir, no, esto no está optimizado y me gusta así. Me gusta así. Muy bien. Otra pregunta, que es un poco general, que es ¿cuáles, si las hay, son buenas razones para no usar esto? Porque muchas veces damos respuestas y depende. Entonces, ¿cuál es el otro lado de este depende? Para mí, en realidad creo que todos deberían al menos intentar activar esto en su base de código. El equipo de Meta ha hecho mucho trabajo para tratar de asegurarse de que entiende completamente JavaScript y las semánticas de React. Han hecho pruebas sobre el uso de memoria y cómo esto realmente afecta los tiempos de montaje, los tiempos de renderizado, los tiempos de actualización. No necesariamente va a hacer que cada aplicación sea 5,000 veces más rápida, y podría haber un poco de aumento en el tamaño del paquete. Pero en principio general, creo que básicamente todos deberían volver e intentar instalar esto en sus proyectos y ver los resultados. No debería empeorar las cosas, y debería mejorar varios aspectos del rendimiento. Y volviendo a esa pregunta que tuvimos sobre el aprendizaje también, la siguiente es que hay muchas optimizaciones de rendimiento que están incluidas de forma gratuita en el compilador de React.

¿Y está bien para nosotros simplemente apagar nuestros cerebros y decir, oh, funciona? ¿O realmente crees que es importante que los ingenieros entiendan cada pieza de código y optimización que está sucediendo bajo el capó? Los ingenieros de software nunca han entendido cada bit de código. Eso es lo que estaba diciendo hace un minuto. Cuando escribo código JavaScript, hay tantas capas de abstracción bajo el capó de las que no tengo que preocuparme. Parte del objetivo de React es que no tengamos que pensar en escribir actualizaciones del DOM a mano. Así que nunca entenderás todo, pero como dije varias veces, cuanto más entiendas los fundamentos de las herramientas que estás usando y al menos entiendas el siguiente nivel hacia abajo, qué es, por qué está ahí, mejor podrás pensar en cómo funciona tu programa.

Así que con el compilador, quiero decir, en realidad acabo de explicar la mayor parte de lo que hizo. Si no lo entiendes, por favor mira la charla de nuevo. Pero también es algo que probablemente deberías poder activar y en su mayoría no pensar en ello. Genial. Así que mi siguiente pregunta es que dado que useMemo en sí mismo tiene un tipo de costo computacional, ¿cómo decides cuándo una computación es lo suficientemente costosa como para justificar la memoización? ¿Tienes alguna regla práctica o algún enfoque de perfilado para tomar esa decisión? Es gracioso que menciones eso. Así que una de las otras charlas de conferencia que he estado dando este año es literalmente sobre cómo realizar investigaciones de rendimiento. Así que un anuncio para mi otra charla que he hecho. He pasado mucho tiempo haciendo investigaciones de rendimiento en mi carrera, y como, mini versión de la charla. Nadie enseña cómo depurar, pero todos aprendemos a depurar porque tenemos que entregar código que realmente funcione.

Pero nadie enseña cómo hacer investigaciones de rendimiento y nadie realmente pasa tiempo investigando el rendimiento porque todo lo que nos importa es si CI estaba en verde, si la prueba pasó, si se ejecutó, envíalo. No pasamos tiempo verificando si el código era más rápido, si hicimos las cosas más lentas. Y así hay muchas herramientas que puedes usar para hacer investigaciones de rendimiento desde los perfiles de CPU integrados en el navegador, el perfilador de herramientas de desarrollo de React, muchas otras herramientas que puedes usar para hacer comprobaciones de rendimiento. Y así la respuesta real es medir toda tu aplicación, ya sea los componentes o el tiempo de ejecución de JavaScript entender dónde las cosas son lentas. Como si una sola llamada de función toma .01 milisegundos para ejecutarse, no hay razón para optimizar eso. Déjalo correr cada vez. Así es como React funciona en primer lugar. Pero si haces comprobaciones de rendimiento en, ya sabes, toda la aplicación, y ves que este componente es consistentemente lento.

¿Por qué es lento este componente? Porque está llamando a esta función de transformación masiva cada vez. De acuerdo. Ahora me he centrado. Ahora veo la evidencia de que esto es lento. Pero como la regla número uno de las investigaciones de rendimiento es medir, entender dónde es lento, y luego averiguar por qué es lento.

Genial. Y luego la siguiente pregunta viene de Robert. Así que muchas personas podrían estar emocionadas por esto, podrían querer ir y usarlo de inmediato. Y ya tienen una base de código existente y quieren activarlo. ¿Cómo se ve eso? ¿Es simplemente un interruptor y empezar a quitar use memos?

¿Hay algún tipo de proceso de transición que recomendarías para las personas? Es prácticamente eso. Como dije, es principalmente un plug-in de herramienta de construcción. Los documentos de React tienen las instrucciones sobre cómo puedes configurarlo. Pero es básicamente añadir un plug-in a tu configuración de construcción y volver a ejecutar tu construcción y hace todo de manera invisible como parte del proceso de construcción de la misma manera que la transformación de JSX a JavaScript plano ocurre en el proceso de construcción. Genial. Ahora estamos casi sin tiempo. Así que voy a salir rápidamente de las preguntas y decir, como, muchas personas han estado preguntando tantas preguntas. Quieren saber más.