React 19 y el compilador para el resto de nosotros

Hola a todos. Muy contento de estar aquí para hablar sobre React 19 y el compilador para el resto de nosotros. Primero, una nota rápida sobre mí. Me llamo Johnny. Quiero decir, mi nombre completo en alemán sería Johannes Bernhardt, pero nadie lo usa. Así que solo refiéranse a Johnny si quieren hablar conmigo más tarde.

Actualmente trabajo en Synthesia. Sizzle fue un trabajo anterior, pero estoy combinando mi experiencia con React 19 de ambos trabajos porque en Sizzle usamos React 19 bastante temprano, pusimos en la beta, pusimos en el compilador. Así que ejecutando producción en Synthesia, ahora estamos moviéndonos a usar el compilador en algunos lugares y el puerto de React 19 más tarde.

Podrías preguntar, bueno, ¿qué significa el resto de nosotros? El resto de nosotros en este caso significa que solo estoy hablando de React 19 como un ingeniero de aplicaciones que está construyendo aplicaciones donde el usuario pasará múltiples horas. Así que no es desde una perspectiva de comercio electrónico donde cuenta los milisegundos para nosotros. Es realmente importante. ¿Tiene el usuario una buena experiencia de rendimiento después de estar en la página durante seis horas tal vez? Y así todo está enfocado en eso. Y vamos a hablar un poco sobre el compilador, pero también hacer una charla por mi cuenta sería un poco aburrido. Así que traje algo de apoyo como las personas anteriores, pero no en persona. Saludos. Soy Bernhardt III y me encanta defender mi castillo de rendimiento con una buena memorización. Hola, amigo. Soy John Rackham y escribo mi código como vivo, salvaje y libre. Bueno, y creo que los tres juntos cubriremos una amplia gama de experiencias mirando a React 19.

Entonces, ¿cuál es nuestro objetivo para hoy? Bueno, nuestro objetivo es simple. Queremos ayudarte a alcanzar la cima de producción con React 19, pero antes de que podamos zarpar, voy a dar el primer paso, necesitamos reunir un equipo. Así que voy a hacer algunas preguntas a la audiencia solo para ver dónde estamos con React 19 ya o no. Luego vamos a hablar sobre los motivos. ¿Por qué querrías instalar el compilador en tu base de código? Quiero decir, JavaScript ya es lo suficientemente lento en el proceso de construcción de todos modos. Y luego solo tenemos un rápido regreso a la isla vintage. Vamos a hablar sobre la memorización porque si agregas un compilador para agregar memorización, probablemente queramos conocer la memorización en profundidad. Luego simplemente vamos a hacerlo. Vamos a instalar React 19. Vamos a ver qué le pasó a nuestra base de código.

Luego aprendemos algo nuevamente sobre las reglas de React y que a veces no deshabilitar las reglas de lint es, bueno, la mejor idea. Así que vamos a echar un vistazo rápido a las reglas de React. Luego hacemos la escalada del compilador. La escalada del compilador significa que solo miramos dos o tres ejemplos para ver qué hace un compilador a este código. Y luego estamos en la montaña de producción y luego cantamos una canción. Bueno, espero obtener algo de apoyo al final porque ahora somos una tripulación, así que vamos a cantar algunas canciones marineras. Así que hagámoslo.

Bien. Preguntas para la tripulación primero. ¿Quién es del equipo noche? ¿Quién está agregando use callbacks en todas partes como un gran grito por favor. Bien. Bueno, no son tantas personas. ¿Quién es del equipo corsario? ¿Equipo pirata? No, ¿no? Bien. Bueno, ¿y quién sigue usando React 17 en su base de código por todas partes? Bueno, estoy hablando de React 19. Pero tal vez lleguen a 18 primero. Pero también hay buenas noticias para ustedes al final. ¿Y quién ya está usando 19 en producción? Porque quiero decir, el lanzamiento fue la semana pasada. Muy bien. Bien. Entonces estoy feliz de poder compartir algunas experiencias sobre eso. Muy bien, hagámoslo.

¿Cuáles podrían ser los motivos para agregar un compilador a tu aplicación? Creo que demos un paso atrás a los años 80. Hay un libro famoso llamado, bueno, el libro del compilador Red Dragon. Tienen una cita que quería traer. Quiero decir, como, oh, bueno, libro súper interesante. Definitivamente puedes revisarlo si solo quieres saber un poco más sobre las técnicas de ciencias de la computación. Pero la cita dice simplemente que un compilador es un programa que puede leer un programa en un idioma, el idioma fuente, y traducirlo en un programa equivalente en otro idioma, el idioma objetivo. Un papel importante del compilador es informar cualquier error en el programa fuente que detecte durante el proceso de traducción. Creo que hay dos o tres puntos muy interesantes aquí. Primero, generalmente usas compiladores para traducir de un idioma a otro.

El compilador de React traducirá de JavaScript a JavaScript. Así que realmente no es otro idioma, pero se verá bastante diferente. Pero lo verás en el cliente del compilador. Y la otra cosa es que necesita reportar errores. Definitivamente puedo decir que reporta muchos errores. Así que eso está definitivamente cubierto. Y vamos a echar un vistazo a eso más tarde.

OK, ahora podrías preguntar, ¿por qué queremos agregar un compilador? Bueno, creo que probablemente hay dos o tres razones principales por las que querrías usarlo. Pero preguntémosle a Bernhard eso. Yo ya escribo el mejor código. Exactamente. Así que hay mucho de esta postura de que no necesito un compilador. No necesito optimización. Conozco todo mi código de todos modos. Pero lo que hemos estado viendo recientemente es que se trata de acumular abstracciones. Ninguno de nosotros se preocupa por los electrones o fotones o los transistores en tu CPU más, en la CPU del usuario. Nos preocupamos por un lenguaje de muy, muy alto nivel. Solo lo que está sucediendo en el navegador. Y hay una gran desconexión de lo que está sucediendo a nivel físico. Y todo eso es posible mediante la compilación en múltiples capas. Y necesitas un compilador para eso. Ya no quiero escribir el binario para mostrar una imagen en la pantalla de mi usuario. Eso sería una locura. Así que estamos acumulando abstracciones. Y en ese sentido, en LLM, cuando escribimos código, también es un compilador. Está traduciendo nuestros pensamientos en el código. Así que, bueno, es un proceso de compilación. Solo que el informe de errores no es tan bueno allí con los LLMs todavía. Pero tal vez eso mejore. Otra cosa, optimizaciones de rendimiento.

El compilador puede llegar a un nivel mucho más profundo de optimización del que querrías hacer manualmente. {{^}}El compilador puede conocer la arquitectura objetivo de la CPU. O puede conocer la arquitectura objetivo de, bueno, el runtime de React para el que estamos compilando. Y puedes centrarte en lo que la aplicación realmente debería hacer por su usuario. Porque ese es mi trabajo principal como ingeniero de aplicaciones. Quiero darle al usuario una buena experiencia. A ellos no les importa la tecnología que está funcionando. Así que déjame centrarme en eso. Y dejemos que el compilador optimice las cosas.

De acuerdo. Pero, ¿qué piensa Rackham sobre eso? Porque dijimos que queremos compilar cosas. Queremos memos. Pero… La memorización consumirá toda tu RAM. Exactamente. Creo que ahí es donde entramos en la postura de la comunidad de React. Que la memorización consume toda la RAM y definitivamente no deberías hacerlo. Y de todos modos no funciona. Creo que la primera diferenciación que necesitamos hacer allí es entre memoria de pila y de montón. No estoy seguro de quién tuvo eso en las clases de universidad de ciencias de la computación. Pero el principio básico es que tienes el montón. Eso es como la memoria general que tu aplicación usa a largo plazo. Y luego tienes la pila de las operaciones actuales que estás ejecutando. Y la pila crecerá. Y si renderizas más componentes, la pila crecerá más y más y más profundo. Puedes mirar el… Activa el perfilador en Chrome. Echa un vistazo a las pilas que se están construyendo. Verás que habrá mucho uso de memoria allí. Así que si podemos memorizar algunos de los componentes y omitir partes del árbol de renderizado, usaremos menos memoria en la pila. Así que simplemente decir que usarás más memoria con la memorización es, en mi opinión, simplemente incorrecto. Necesitas diferenciarlo mejor.

¿Qué pasa con los children? Exactamente. ¿Quién escuchó eso? Como, no uses memos porque no funcionará con children. Así que, bueno, vamos a profundizar porque eso en realidad no es cierto. Y ese es un principio importante que el compilador usará. Lo siento si eso te resulta muy familiar. Volveremos a eso más tarde por qué necesitamos eso.

Así que memorización. Un ejemplo simple. Hagamos esto. Así que solo tenemos un contador. Y puedes hacer clic en él y está aumentando el conteo. Y luego tenemos otra función de conteo de render aquí que solo está tomando una ref y contando render allí. Entonces, ¿cuál es el conteo de render si hago clic en el botón? ¿Alguien puede decir dos? Incorrecto, porque el modo estricto está activado. Bien, no, pero apagué el modo estricto para los otros ejemplos aquí.

En el siguiente ejemplo, solo estamos agregando un memo aquí. Así que hago clic en el botón, el modo estricto está desactivado de nuevo. Así que hago clic en el botón una vez y el conteo de render es uno. La memorización funciona, todo está bien. Pero luego comienzas a agregar, está bien, tengo algunos children aquí. Así que en el conteo de render estoy pasando algún párrafo o algún texto. Así que hago clic en el botón, ¿qué pasará? Bueno, el conteo de render es dos ahora, porque ¿por qué? Tuve que crear un nuevo elemento de React aquí y eso siempre es algo nuevo. Pero luego piensas, está bien, ¿entonces nunca puedo usar memo si estoy pasando children? Y luego podrías intentar algo como, está bien, bueno, solo pongamos algo de texto aquí, ¿verdad? Y tengo el memo aquí. Entonces, ¿alguna suposición, cuál será el conteo, el conteo de render? No, en realidad es uno. Porque React está comparando los children allí y obtienes la cadena como children, es la misma cadena. Todo bien, no voy a renderizar el componente. Y podemos llevar ese ejemplo un poco más allá. En este caso, no estamos usando una cadena de nuevo, estamos usando un párrafo, pero lo estamos poniendo en un use memo y luego solo pasando el child interno. Así que ahora todos deberían esperar las respuestas como que el conteo de render no va a cambiar porque pasamos los mismos children. Así que sí, puedes usar memos para children, funciona perfectamente bien. Así que la lección principal aquí es, sí, puedes memorizar JSX y el compilador lo estará haciendo en todas partes.

Muy bien, estamos listos. Sabemos por qué queremos usar un compilador. Tenemos nuestra antigua base de código de React18. Entonces, ¿cuál es el siguiente paso? Quiero decir, bastante simple. Simplemente vas a tu línea de comandos e instalas la última versión de React. Y luego ves. Veamos qué pasa. ¿Alguna suposición? ¿Funcionará simplemente? ¿Habrá problemas?

Bueno, quiero decir, en realidad me despedirían de mi trabajo porque hay un gran mensaje de error diciendo que los internos secretos no se usan, así que serás despedido. Eso me recuerda un poco a trabajar en Twitter en 2022. Bueno, eso fue hace mucho tiempo. Y ese es un ejemplo de Sizzle. En este caso, ahora hemos estado usando el runtime de preact signals para alguna subbiblioteca del monorepo solo para probarlo, pero eso falla. Así que en caso de que estés usando alguna cosa loca conectándote al runtime, probablemente quieras verificar si puedes deshabilitar eso antes de querer simplemente pasar a React 19. De lo contrario, recibirás mensajes de error como este.

Y luego el siguiente paso, obviamente, necesitas habilitar el compilador. Quiero decir, lo primero que realmente deberías hacer es leer el manual de la página de React. Tengo una o dos áreas donde diferiría ligeramente del manual. Así que solo te voy a dar los consejos para que puedas seguir adelante cuando solo quieras hacerlo. Así que la configuración es bastante como un archivo de configuración llamado compilador, algo donde enumeras las carpetas y reutilizas esa lista de carpetas en una expresión regular. Así que solo obtén alguna función de utilidad que esté creando tu expresión regular para capturar todas las carpetas para la A y B y alguna carpeta de origen. Y porque entonces puedes usar ese patrón en la configuración del compilador de React para probar qué archivos realmente quieres tener el compilador habilitado. Pero lo bueno es que puedes reutilizar la lista de carpetas también en tus archivos ESLint. Así que estás seguro de que es como lo mismo que está sucediendo. Y luego tienes como alguna configuración de Babel en nuestro caso porque estaba usando nuestro proceso de construcción donde solo dices, voy a usar la configuración del compilador aquí y pasarla a través de todos nuestros archivos JavaScript con un patrón de Babel. Todo eso depende mucho de tu configuración de construcción local. Así que realmente no tiene sentido profundizar. Solo echa un vistazo a la documentación, realmente, pero solo toma el consejo de crear una lista y compartirla.

Muy bien. Así que hicimos eso. ¿Qué pasa? Bueno, funciona.

Sí. Vemos un componente compilado. ¿Cómo puedes verificar eso? Asegúrate de instalar la última versión de React DevTools. Verás estos bonitos botones de estrellas de memorización azules, pero luego te preguntas, está bien, habilité el compilador para muchos más archivos. Entonces, ¿qué está pasando en mi aplicación aquí? Y luego estás investigando como, está bien, bueno, ¿qué dijimos sobre los compiladores antes? También se trata de la generación de informes de errores. Así que si echas un vistazo rápido al registro de ESLint, vemos que el compilador de React omitió optimizar este componente porque una o más reglas de ESLint de React fueron desactivadas. Así que una pregunta rápida, ¿quién de ustedes desactiva regularmente las reglas de ESLint? Bueno, al menos algunas personas en el frente, lo cual, bueno, yo también hice eso en la base de código. Entonces, ¿qué puedes hacer al respecto? En nuestros casos, creo que hay como dos cosas principales que van a suceder. El primer caso es, tienes algunos efectos en algún lugar y eso está diciendo como, oh, bueno, no quiero volver a renderizar, pero resulta que en realidad depende de algo que es estable porque usas otro hook aquí en este caso que estaba devolviendo una acción estable. Así que también podrías simplemente poner la acción en el área de dependencia, va a estar bien, y luego ese componente se compilará bien. En otros casos, podrías tener algunas dependencias donde estás omitiendo. Así que como este código aquí podría usar la referencia B, pero en el área de dependencia, solo tienes referencia A y C, y hay alguna lógica de negocio detrás de eso. En este caso, bueno, simplemente apila otra regla de desactivación de ESLint en la siguiente línea y, wow, también funciona. Pero eso significa que el archivo aún no se compilará, simplemente no recibirás la advertencia en tu lint. Así que eso podría ser importante dependiendo de cómo esté configurado tu CI. Está bien, sigamos adelante.

Y luego tienes este ejemplo, estás como, está bien, ¿por qué se queja el compilador sobre esto? Estoy como, esto parece que tengo ref, tengo algún controlador de desplazamiento y lo estoy adjuntando a la ventana y como, ¿por qué se queja el compilador? ¿Alguna suposición? Muy bien, traje algo de ayuda para mirar esto para un rápido repaso de las reglas de React. Así que hagámoslo aquí por Bernhard. Déjame ayudarte. Hay tres reglas principales. Uno, los componentes y hooks deben ser puros. Dos, React llama a componentes y hooks. Tres, reglas de hooks. Bueno, creo que la tercera regla es un poco mala, pero es la forma en que está en la documentación de React, pero puedes reescribir eso como código abierto. Solo se llaman hooks en el nivel superior de las funciones de React. Así que, está bien. ¿Tenemos alguna idea ahora? Bueno, en realidad es la primera regla. Los componentes y hooks deben ser puros. ¿Cuál es el problema aquí? El problema aquí es como estamos usando este ref, pero solo se te permite realmente acceder al ref, bueno, en callbacks. No se te permite acceder al ref en tiempo de renderizado porque eso hace que tu función no sea pura.

Y el problema aquí es que sabemos que esta función de callback no se llamará hasta mucho más tarde porque la función load-throttle no está llamando a la función interna, pero no hay forma de que el compilador sepa que la función throttle no llamará inmediatamente a esta función y esta función se llamará cuando usen memo update. Así que se llamaría en el primer ciclo de renderizado. Así que el compilador está diciendo, no sé qué vas a hacer aquí. Así que no puedo compilar esto. Entonces, ¿cómo podemos resolver esto? Bueno, podemos simplemente reordenar un poco el código. Todavía tenemos nuestro controlador de desplazamiento arriba, pero creamos la versión throttle justo en el efecto porque esta referencia ahora es estable ya que no hay dependencias aquí. El use effect también solo se activará una vez. Así que creamos una copia throttle y simplemente la usamos. Y eso ahora está totalmente bien para el compilador porque el use effect ocurrirá más tarde y no ocurrirá en tiempo de renderizado. Así que es seguro que la referencia del botón no será accedida. Así que si te encuentras con esto, siempre piensa que probablemente te encontrarás con esto como mucho, al menos como una base de código de una hora sucediendo con refs y luego nadie fue realmente estricto sobre no usarlos. Tiempo de compilación. Muy bien. Así que solucionable. Y si haces eso en muchos lugares en tu base de código, bueno, tu herramienta de desarrollo se verá así. Está mucho más compilada. Así que eso es encantador.

Entonces, la siguiente pregunta que podrías hacer es, bueno, compilémoslo ahora. ¿Qué significa realmente? Así que hagamos un cliente de compilador rápido. Vamos a echar un vistazo rápido. ¿Qué está haciendo el compilador? Bueno, ejemplo súper simple, compilador de React. Tenemos este, bueno, componente muy simple, solo devuelve como un dev estático. Hello world. Oh, bueno, ahora es más código. Eso debe ser más complicado. Así que echemos un vistazo rápido.

La primera línea solo dice, bien, dólar igual a C1. No tengo idea de lo que está pasando, pero volveremos a eso más tarde. Luego variable temporal. Ah, bien. Así que está usando el dólar para verificar algún centinela de caché. Y luego está, oh, eso está generando mi componente. Bueno, el componente interno ahora. Y luego está asignando eso al signo de dólar. Y si es, así que quiero decir, lo que está pasando es bastante simple.

Es solo un use memo de una manera ligeramente diferente. Solo verificamos, y esto es solo como un array de cosas que podrías almacenar en el componente que podrías querer usar más tarde. Así que, en esa lista, solo verificamos, bien, ¿tenemos como un valor vacío? Y luego creamos el componente interno. Y luego devolvemos el componente interno. Y si ya tienes el componente interno allí, simplemente lo devolvemos de nuestro caché allí. Y si quieres, ahora podrías preguntar, bien, entonces, ¿qué está haciendo la C aquí? Bueno, React es de código abierto. Así que podemos echar un vistazo rápido al runtime del compilador de React. Una nota rápida allí, podrías no haberlo sabido aún. El compilador de React es en realidad TypeScript. Así que no lo escribieron en flow, de lo cual estoy muy contento. Pero así que es TypeScript, así que podemos echar un vistazo rápido. Lo primero que notamos si React.C ya está presente, estás como, bien, ¿qué está pasando? Pensé que solo podía usar el compilador con React 19.

Bueno, en realidad no es cierto. Puedes usar el compilador de React con 17 o 18 siempre que tengas soporte de runtime para ello. Así que nada te impide simplemente usar el compilador ya. Y luego, así que solo está usando eso si está presente. Si eso no está presente, oh, bueno, usemos memo de nuevo. Y luego ves, es como inicializar el array del tamaño dado. Así que en nuestro caso, habríamos obtenido un array de tamaño uno. Y bueno, solo está poniendo el símbolo vacío aquí para marcarlo como vacío. Y luego está haciendo algo para la profundidad.

Así que quiero decir, al final, es solo como una lista de cosas que podrías querer usar más tarde en la función. Así que hagamos un ejemplo un poco más complicado para el compilador. Pero la recomendación es definitivamente echar un vistazo al playground del compilador. Es genial. Puedes ver como muchos, hay como 20 diferentes pasos que el compilador puede hacer. No tengo tiempo para entrar en todos estos. Así que necesitas revisar el playground. Solo hay un gran problema. No tiene un tema de color oscuro. Horrible. Lo siento por eso. Pero echemos un vistazo rápido a esto.

Bien. Así que este es nuestro ejemplo de conteo de antes. Y lo primero que notarás, oh, bueno, ahí está nuestro mensaje de error de nuevo, porque estamos usando la ref en el ciclo de renderizado. Así que el compilador de React realmente se detendrá al compilar este componente de conteo de renderizado. Pero compilará como el componente de aplicación en la parte superior. Entonces, ¿qué está pasando aquí? Podemos simplemente mapear fácilmente o relativamente fácilmente.

Bien. Lo primero es que vemos como el hijo interno aquí. Así que estamos usando un use memo aquí. Y en nuestro caso aquí, en realidad ya no hay use memo porque el compilador está eliminando todos los use memos. Y solo está diciendo, bien, similar al ejemplo anterior, solo estoy creando como este componente hijo estático, poniéndolo en la caché en la ranura cero. Y solo voy a hacer eso una vez. Y luego sucede algo interesante porque el compilador sabe que esto en realidad no va a cambiar. Solo voy a inicializar esto una vez. También solo voy a inicializar la función de conteo de renderizado una vez, porque si este hijo interno nunca cambia, también puedo almacenar en caché como esta área aquí del conteo de renderizado del hijo interno del conteo de renderizado. Y vemos que esto sucede aquí. Donde también solo está diciendo, bien, bueno, pon el conteo de renderizado del hijo interno en la caché en la ranura cuatro y luego devuelve eso. Bien.

Ahora podrías decir, bueno, eso es un poco aburrido. Entonces, ¿qué está pasando cuando algo realmente está cambiando, podemos echar un vistazo a las cosas de count aquí porque eso va a cambiar. Y en realidad también podemos ver lo que el compilador está haciendo por nosotros porque vemos como el set count aquí. Estoy como en una función, no hay use callback. Estaré bastante descontento con eso en producción, pero afortunadamente el compilador está creando una referencia a la función set count solo una vez en este bloque. Y luego está usando esa referencia en el, bueno, tercer área aquí. Y ahí también vemos como, bien, entonces si el count cambió, voy a, porque almacenamos el count en la ranura dos, si el count cambia, voy a crear como un nuevo botón. Y luego en las diferentes ranuras, voy a decir como, ¿qué count usé? Y luego el componente resultante. Y luego si estoy renderizando de nuevo, voy a verificar, bien. Entonces, ¿cuál es mi count en la ranura dos? Si es similar, solo voy a devolver el botón en caché. Bien. Así que quiero decir, todo es bastante simple. Todavía parece un poco JavaScript. Así que el lenguaje realmente no se traduce, pero también se ve bastante diferente, pero estoy como, solo quédate en el playground. Lo entenderás.

Bien. Entonces, siguiente pregunta. Podría tener una solución aquí. Entonces, ¿qué podemos hacer sobre el conteo de renderizado? Bueno, solución simple. Pones tus cosas inseguras en un hook llamado privateer porque entonces la función de conteo de renderizado puede compilarse bien y solo tienes las otras cosas en otro lugar y esto simplemente no será optimizado. Y luego ves que el conteo de renderizado también está compilado. Genial.

Muy bien. Quiero decir, hemos alcanzado la montaña de producción. Bien. ¿Cuáles son mis experiencias al poner React 19 en vivo, al menos en Sizzle? La primera cosa es que el inicio de tu servidor de desarrollo podría ser un poco más lento porque no usamos Babel en ningún lugar. Ahora estamos usando Babel a través del compilador de React y obviamente hay algo de sobrecarga, lo cual es un poco triste, pero así es ahora, pero vale la pena porque obtenemos reactividad granular. Eso significa que usualmente, me encanta poner use memo en todas partes, pero también soy un poco perezoso. Así que podría poner demasiadas cosas en un solo use memo solo para tenerlo algo memorizado.

Pero eso significa que si calculo tres valores diferentes, solo dos de ellos deberían actualizarse. El tercer memo podría memorizarse de manera diferente y el compilador lo hace automáticamente por mí. Y está haciendo notablemente menos renderizado, lo cual a nuestros usuarios les encanta porque la aplicación se siente más rápida. Y funciona absolutamente bien con React 18. Estamos haciendo eso en Synthesia ahora. Estamos comenzando a poner algunas de las carpetas de origen en React 18 con compiladores. También está funcionando bastante bien. Así que mi opinión es simplemente hazlo realmente.

Bien. Así que última diapositiva de la charla. Rápida, rápida línea de canción marinera. ¿Quién conoce esta canción marinera alemana de 17 Mann auf des Toten Mannes Kiste, Jo, Ho, Ho, ne Buddel voll rumm? Bueno, no necesitas hacer eso porque ahí no es donde reaccionamos a ti, pero vamos a reescribir esto. Y esto, muy bien. Ahora necesito algo de apoyo. Voy a hacerlo una vez por mi cuenta y luego pediré su apoyo. Quiero decir, no tienes que hacerlo, pero entonces se ve estúpido.

Okay. 19 Mann auf der React-Versions-Liste, Jo, Me, Mo, ne Buddel voll rumm? Bueno, al menos los alemanes.

Okay. Así que hagámoslo. 19 Mann auf der React-Versions-Liste, Jo, Me, Mo, ne Buddel voll rumm? Encantador. Eso es todo.

Primero que nada, me encanta el hecho de que también tuvieras una canción marinera al final. Yo, desafortunadamente, porque no hablo alemán, no puedo, no pude unirme, pero lo que haré es tal vez tomaré tus diapositivas y la traduciré y luego probablemente la cante la próxima vez. La próxima vez que lo hagas. Estoy como, deberíamos hacer una línea en la fiesta posterior. ¿En la fiesta posterior? Okay. Veremos. Veremos. Veremos. No voy a hacer ninguna promesa. No voy a hacer ninguna promesa.

Muy bien. Tenemos un par de preguntas que han llegado. Recuerda, piensa en cuál es tu favorita también, porque esa persona recibirá un premio, pero voy a ir directamente a la pregunta más votada, que es sobre el rendimiento. Y es de Flip. ¿Encuentras una diferencia medible en el rendimiento de la aplicación después de introducir el compilador en producción? O en... No estoy...

¿Está en producción en Sizzle dijiste? Está en producción en Sizzle. Fue un cambio rápido para llevar React 19 a producción, ¿verdad? Bueno, solo pusimos la versión beta en producción. ¿Una versión beta en producción? Eres valiente. Quiero decir, el mundo de los juegos se está moviendo rápidamente. Justo. Justo. Pero, sí, pero el punto...

Quiero decir, puedes activar los DevTools. Verás... Y pones el modo de parpadeo y verás menos destellos azules. Así que es genial. Además, sorprendentemente con React 19, los tiempos de carga entre páginas mejoraron. Así que hay menos renderizado notablemente. Realmente no puedo compartir estadísticas, lo siento por eso, pero está funcionando hasta ahora.

Bien. Y estoy bastante seguro de que si pueden encontrarte en el Q&A, puedes hablar tal vez de algunos de los lugares específicos donde viste los aumentos de rendimiento. Sí, absolutamente. También.

Tenemos otra pregunta que viene de alguien, que está preguntando sobre si es seguro usar el compilador de React en una aplicación que utiliza bibliotecas pesadas de React, tal vez como un AG Grid y MUI. ¿O tienes que investigar bastante sobre la compatibilidad? Bueno, muy buena pregunta. Y creo que la respuesta necesita múltiples capas. Así que lo primero es que el compilador aún no está mirando el código de la biblioteca porque solo compilará la lógica de tu aplicación encima de ella. Así que si quieres la versión compilada de la biblioteca, necesitas construirla desde la fuente y habilitar el compilador encima de ella o necesitas esperar a que lo haga upstream. Y luego la cosa es, mientras sigan las reglas de React, todo estará bien porque eso es en lo que se basa el compilador de reglas. Este acuerdo de que todos seguimos las reglas de React. No hacemos optimizaciones extrañas porque pensamos que podemos hacerlo mejor. Y creo que esta es también una de las razones por las que a veces la gente realmente no quiere usar callback o usar memo en todas partes. Están pensando, bueno, conozco el código que estoy usando aquí. Sé que va a ser mejor de esta manera. Sí, pero ¿tu yo futuro en tres semanas sabe que optimizaste esta área? Probablemente no. ¿Tu compañero de trabajo en dos años sabe que tienes una optimización de rendimiento extraña allí? Probablemente tampoco. Así que necesitamos tener este acuerdo de siempre seguir las reglas. Y así tenemos convenciones sobre las que podemos construir. Y si no rompes las convenciones, el compilador generalmente estará bien. Todavía es oficialmente una versión beta. Así que dependiendo de tu base de clientes, tal vez no quieras hacerlo. El único área donde podrías tener problemas, realmente, es si estás haciendo cosas extrañas con referencias.

Si estás haciendo cosas raras con tus propios hooks personalizados y simplemente no sigues realmente el ciclo de vida estándar, entonces realmente necesitas más pruebas. Lo bueno es que también puedes excluir funciones individuales del compilador. Puedes simplemente agregar una directiva, usar no memo en la parte superior del componente, y no será compilado.

Eso tiene sentido. Eso tiene sentido. Además, solo esperando que todos sigan las reglas. Eso es un poco de pensamiento ilusorio, para ser honesto. Bueno, soy alemán. No, seguro.

Y la siguiente pregunta es, entonces sobre use memo y usar callbacks. ¿Eso los hace prácticamente inútiles? Bueno, quiero decir, los hace inútiles en el código. Eso está compilado, sí. Así que puedes estar feliz de no pensar más en eso. ¿Y cómo afecta el uso del compilador, esto es de Alex, al tiempo de construcción? ¿Lo aceleró? ¿Lo ralentizó? No, quiero decir, como mencioné en la diapositiva, no, el tiempo de construcción definitivamente está aumentando. Probablemente más si aún no estás usando Babel, porque eso significa que activas todo el análisis de Babel y lo que sea. ¿Cuánto, solo como una cifra aproximada? Entonces, el tiempo de inicio, que es como compilar la mayoría de los archivos en nuestro caso, es como un 40% más, solo por la sobrecarga de Babel. Pero eso significa que si inicio mi aplicación localmente, ahora me toma nueve segundos en lugar de cinco. Así que bueno, no, es más, bueno, es más por conjunto que eso, pero algo alrededor de eso. No, seguro.

Y la siguiente pregunta es de Ricardo. Y entonces acabas de actualizar a React 19. ¿Hubo algún desorden inesperado o algo, especialmente todavía está en beta, alguna cosa con la que te encontraste que tal vez alguien que está a punto de probar React 19 debería tener en cuenta? Sí, creo que un desorden ligeramente inesperado es la eliminación del espacio de nombres global JSX. Porque anteriormente, si instalas los tipos de React en tu aplicación, tendrás el JSX disponible globalmente. Pero ahora React está colocando el espacio de nombres JSX debajo del espacio de nombres de React. Así que en cualquier lugar que tu aplicación haga referencia durante JSX, necesitas prefijar React o puede que no funcione. Y un problema que tuvimos en Synthesia en este momento es que estamos usando Emotion. Y Emotion no se actualizó a React 19 todavía porque está cambiando un poco con los tipos. Y quiero decir, como si estuvieras haciendo todos los envoltorios estilizados, están envolviendo sobre el espacio de nombres JSX en los tipos de TypeScript y eso ya no funciona. Puedes hacer algunos trucos como reexportar el espacio de nombres JSX globalmente con un archivo de definición de TypeScript. Pero deberíamos estar más avanzados en las reglas.

Exactamente. No, seguro. Das, muchas gracias.

Y tenemos tiempo para una pregunta más. Esta es de Marvin y se trata de depuración. Así que, por ejemplo, en Chrome, ¿hay mapeo de origen, las herramientas de depuración están funcionando bastante bien? Realmente me gustaron las herramientas de depuración donde podías ver dónde use memo fue automáticamente, fue colocado automáticamente por el compilador. Sí, no, quiero decir, el mapeo de origen funciona bien. Y lo bueno también es, al menos en mi opinión, sigue siendo como JavaScript. Así que quiero decir, si ves la salida del compilador, todavía puedes leer eso y es un poco complicado. Necesitas acostumbrarte a ese estilo, pero luego también es relativamente fácil simplemente mirar la salida directa del compilador y ver qué está pasando. Así que sí, no hay problema allí.

Genial. Y la última, esta, también estoy de acuerdo con esta persona. ¿Puedes traducir el canto C justo antes de que nos vayamos? Absolutamente. Así que como la versión actualizada, bueno, está diciendo como 19 hombres en el react. Como dice, bueno, cambié un poco la canción. Como en el significado original en alemán, son 19 hombres en el cofre del muerto. También hay una versión en inglés. Tú estás en una botella de ron. Sí, exactamente. Así que es lo mismo. Pero el alemán actualizado es como haciendo el signo de exclamación. Así que está diciendo 19. Sí, en la lista de versiones de React, porque puedes usar man de diferentes maneras en alemán. Y el segundo, bueno, quiero decir, creo que entiendes eso.

Genial. Muy bien. Ahora, de esas preguntas que acabamos de tener, ¿alguna que te haya llamado la atención le dará a la persona que hizo la pregunta un maravilloso día de React. Quiero decir, me encantó la pregunta sobre los cantos. Ahora, te encantó la pregunta. Oh, no era mía. En realidad no era mía. Era anónima. Así que anónimo, por favor dirígete al frente del escenario. En realidad, te voy a dar la taza y luego en la sala de preguntas y respuestas, anónimo ve y toma tu taza por tu pregunta. Así que muchas gracias, Johannes. Una vez más, es genial tenerte en nuestro escenario. Démosle un aplauso.