Modernizando Tu Aplicación React: Compiler, useEffectEvent, Activity & Amigos

Mi nombre es Victor y estoy aquí hoy para presentarles la historia de un desarrollador, yo, pasando por una base de código y heredando muchas decisiones. Y probablemente como yo, tú también pasas por la misma situación. Cuando obtienes una base de código, ya sabes, no es necesariamente nueva y pasas por muchos memos, use effects, use callbacks, hacks, todo lo que parece un poco extraño. Y probablemente te vas a preguntar, ¿qué puedo hacer aquí? Hay una mejor manera. Y la respuesta probablemente sea sí, pero también requiere tomar acción activa. Y estoy aquí hoy para compartir la historia contigo con casos de usuario reales, ejemplos. Correcto.

Así que mi nombre es Victor Alenkov. Soy un desarrollador de software con más de 10 años de experiencia. He sido gerente, he sido líder técnico. Hoy soy ingeniero de planta en Chili Piper. Trabajamos con LLMs, chatbots y AI. Y estoy aquí hoy para hablarte de cómo puedes aprovechar las últimas actualizaciones de React para hacer tu base de código más limpia, para entender completamente por qué esas herramientas están ahí para que podamos hacer de nuestro trabajo un lugar mejor.

Así que esta es nuestra agenda para hoy. Quería hablar sobre la evolución de React a lo largo de los años para entender realmente cómo están llegando esas actualizaciones y entender profundamente cómo funcionan esas nuevas APIs con React 19.2, cuándo deberíamos usarlas, qué podemos hacer con ellas. Luego te voy a dar este manual de modernización donde puedes seguir paso a paso, como lo hice yo, para aterrizar en tu base de código esos cambios para estar preparado para cambiar. No de una vez, sino con mucha confianza. Y luego vamos a discutir algunas opiniones y tenemos algunas llamadas de atención.

Bien, entonces React 19 nos trajo mucha perspectiva sobre cómo React está evolucionando con el tiempo. Si eres como yo, probablemente te lanzaste directamente a esta versión para entender qué había de nuevo, qué era diferente, cómo React estaba evolucionando. Y realmente ver la diferencia en el paradigma y cómo nos están trayendo esas diferencias.

Entonces, primero, creo que lo más importante es entender la dirección, ¿verdad? Así que básicamente tenemos dos paradigmas aquí. El modelo imperativo donde damos instrucciones paso a paso sobre qué hacer, cómo describir tu estado y esos cambios paso a paso.

Y poniendo esto en un ejemplo real, tenemos formularios en el patrón de React 18, donde tienes tu estado y tienes un estado para errores y tienes tus manejadores, que primero tratarán tu formulario. Luego definiremos el estado de tu spinner, por ejemplo. Y luego vas a hacer la obtención de datos y si algo falla, capturas. Y así es como básicamente tratamos tu estado de fallo y tienes que hacer esto para cada otro formulario y para cada otro estado. Y con el tiempo, puede volverse confuso.

¿Y cuáles son las opciones para esto? Entonces tenemos lo que React está señalando, hacia lo que está evolucionando, que es un modelo más declarativo, donde describes los cambios antes y después, y dejas que la computadora descubra los pasos intermedios. Así que si eres como yo, probablemente ya estés usando, y si no lo estás, quiero que empieces a usar hoy, el use action state, por ejemplo, para formularios, donde podemos usar este hook para describir el estado de un formulario. Tenemos el estado anterior y los datos del formulario, y aquí tenemos un modelo más declarativo para expresar nuestros cambios. Aquí, hacemos la obtención de datos y devolvemos, y luego si algo falla, propagamos el fallo. Así que aquí tenemos en un formulario una manera mucho mejor de detectar esos cambios sin bloquearse entre sí, ¿verdad? Y esto es, sin duda, un cambio de paradigma mayor, porque antes, imagina en aplicaciones, en casos reales, probablemente vas a tener muchos formularios.

Solo piensa en muchos try catchings cada vez. Así que si eres como yo, mi empresa, hoy en día tenemos este chatbot, así que toneladas de formularios para cambiar. Así que esto, para nosotros, fue muy impactante de entender y de implementar. Así que con React 19 y en adelante, podemos ver que nos estamos moviendo hacia todo declarativo, no solo, ya sabes, como estado, como formularios, obtención de datos, metadatos, todo lo que solía ser imperativo. Ahora se está volviendo más declarativo y esto está cambiando, y eso se traslada aún más a la última actualización 19.2. Así que tuvimos el pasado octubre otra muy buena actualización de React donde introdujimos nuevas APIs, y creo que son súper interesantes, y quiero que las adoptemos. Así que aquí en esta nueva actualización, separo cosas que creo que son muy importantes para que traigamos a la mesa y cómo podemos abordarlas.

Así que aquí está más o menos lo que vamos a ver hoy. Así que vamos a tener la actividad, el user effect event, y también tenemos algunas actualizaciones de rendimiento. ¿Y por dónde empezamos? Bien, comencemos por el React compiler. Si viste mi última charla y el anterior React Summit, probablemente sepas que estoy totalmente a favor del React compiler. Creo que el React compiler te ofrece el mayor retorno de inversión porque con una línea de código, puedes hacer mucho. Pero para recapitular, me gustaría repasar los pasos que tomo cada vez que estoy explicando el compilador porque sé que es un tema sensible también. Muchos desarrolladores tienen mucho miedo de tocar el compilador y comprensiblemente, puede parecer mucho. Pero una vez que entiendes cómo funcionan las cosas y en realidad que puedes obtener aún más poder que solo la memorización manual, puedes ver claramente el paso a paso de cómo abordar este tipo de cambio. Así que probablemente si eres como yo, también aprendiste de antes cómo tomar tus componentes, tomar tus acciones, y hacerlos seguros para la memoria, básicamente memorizando todo. Así que para los datos derivados, solías tener el used memo, que puedes, ya sabes, memorizar los resultados de los datos derivados para los manejadores. Sabes, puedes tener used callback para memorizar nuestros callbacks. Y para el componente en sí y los hijos, tenemos el React memo, que estaba, ya sabes, a cargo de la memorización y todo lo demás. Eso está bien. Y sabes, vemos hoy en día que muchos frameworks evolucionaron y tienen esto incorporado por defecto y lo que React hizo, ya sabes, nos trajo esa API para lidiar con estas cosas. En primer lugar, el nombre es un poco confuso. Tenemos used callback, used memo y React dot memo. Y es propenso a errores. ¿Verdad?

Esto es muy manual. Básicamente estamos haciendo el trabajo del compilador a mano. Así que solo se necesita una llamada incorrecta aquí. Así que usa todos los beneficios que obtienes de la memorización. Correcto.

Entonces, ¿cuál es la alternativa? Primero que nada, instalamos el compilador y ejecutamos las verificaciones de salud. Asegúrate de agregar este complemento a nuestra aplicación y desde ese punto en el tiempo de compilación, definitivamente podemos ver los beneficios del compilador, que van mucho más allá de lo que podemos hacer con la memorización manual.

Así que después de habilitar el compilador, todo este componente se convierte en un componente de React limpio donde tenemos nuestros datos derivados, los manejadores y el componente. Es mucho más fácil de entender. Y también es más limpio y más pequeño. Es seguro para tus tokens si la IA está leyendo este código porque es menos código. Correcto. Así que es mucho más fácil de entender para nosotros. Esto es una carga cognitiva mucho menor, lo cual es genial. Con React compiler, básicamente podemos pensar que ya no vas a usar memos. Callback, React dot memo. Son solo funciones. Correcto.

Como no tenemos que preocuparnos por esas cosas. Y luego, si eres como yo, probablemente lo que vas a hacer es intentar medir cuán grande es el cambio en tu base de código ahora mismo. Así que lo que hice fue escribir un pequeño script para identificar cuántas llamadas de hooks de memorización teníamos en la base de código. Y tenemos un montón. Correcto. Y sé que esto puede ser muy aterrador si lo ves de primera mano, si estás en una base de código enorme que, oh, Dios mío. Eso es mucho. Pero te voy a contar más adelante en un playbook cómo abordar esos cambios. No tengas miedo. No tienes que hacerlos como no tienes que eliminarlos. No tienes que cambiar los hooks de memorización que ya tienes. Podemos aprovechar el compilador desde la perspectiva de instalación y evolucionar desde allí.

Bien, la segunda cosa de la que quiero hablar hoy es el user fact event. Que es esta nueva API que crea funciones que ven los últimos props y estado como un manejador de eventos del DOM, pero vive en el mundo de los hechos, lo que básicamente, y más importante, significa que no tenemos que rastrear las dependencias y el linter sabe cuándo excluirlas. Pero déjame ver, déjame mostrarte de qué estoy hablando. Así que en nuestra aplicación en la sala de chat, tenemos, por ejemplo, aquí este pequeño user fact que, ya sabes, pasamos un tema porque el usuario puede definir qué tema están usando. Si es claro u oscuro y mostraré una notificación al usuario una vez que esté conectado a la sala de chat y probablemente puedas ver el como el. Error aquí, que ahora es como o no, tenemos que pasar el tema como una dependencia en el array de dependencias, aunque no cambia en absoluto, tenemos que pasarlo y es bastante molesto. Y lo que vas a ver muchas, muchas veces es gente haciendo este pequeño truco que ponen el ES lint disable next line, el llamado del día y dicen, OK, sé mejor que el linter. Y todos sabemos que, ya sabes, eso no es súper agradable y probablemente muy frágil también. Pero no conocía a mucha gente que realmente supiera cómo resolver esto sin él. Y ahora con React, tenemos esta nueva API.

Así que sabes lo que hice? Como antes, ya sabes, creé un pequeño script, comencé a rastrear esas instancias, encontré muchas de ellas. Y después de usar el user effect event, podemos separar esas cosas, podemos desacoplar esas cosas para tener una base de código más declarativa. Aquí mismo, usas el hook y luego pasas la dependencia solo una vez, ya sabes, como tenemos el conectado y el tema aquí. Y ves ahora que los efectos de usuario se ejecutan completamente libres de esta dependencia. Así que no hay supresión de lint porque aquí usando la nueva API, somos lo suficientemente inteligentes para entender que obtengo los últimos props, pero ya no me afecta este efecto de usuario. Así que básicamente puedo desacoplar esas dos cosas, lo que hace que este código sea mucho más agradable y menos propenso a errores también. Correcto.

La Activity API, es otra gran actualización, que creo que trae muchas nuevas estrategias a la mesa, ¿verdad? Y tengo un montón de casos que traje para que podamos hablar sobre ello. En mi empresa, por ejemplo, tenemos, ya sabes, un paso de moot, es decir, un programador, donde el usuario tiene, ya sabes, que completar el tail a través de tres pasos. Y a veces navegan de ida y vuelta.

Así que las opciones que tenemos hoy, no son tan buenas, ¿verdad? Tienes renderizado condicional, que es barato, pero el problema aquí es que este estado, cada vez que vas de ida y vuelta, simplemente se pierde. Correcto.

Sabes, puedes ocultar cosas usando este truco de display. Pero aquí el problema es, dependiendo del tipo de cosas que estás tratando de ocultar de la UI, si tienes efectos, obtención de datos, ya sabes, como suscripciones, tomando temporizadores y así sucesivamente, y muchos de ellos, básicamente estás desperdiciando tus recursos. Todos están ejecutándose en segundo plano. Así que no tienes ningún tipo de control fino, lo cual es bastante malo.

Entonces. Con la Activity API, podemos evitar esto porque podemos tener una tercera opción, ¿verdad? También podemos evitar el hecho de que, ya sabes, mucha gente intenta hacer esto también para simplemente usar use half como un truco para intentar controlar la capa de persistencia y sortearlos. Pero la Activity API es una API de React Native que nos permite tener un control fino cuando queremos mostrar nuestros datos y por qué.

Así que aquí, por ejemplo, como puedes ver, estamos usando la Activity API y la propia API tiene dos modos. El primero es visible y el segundo es oculto. Cuando el modo está oculto, los hijos están ocultos de las pantallas, los efectos se desmontan, ejecutamos las funciones de limpieza, las actualizaciones se difieren hasta que React esté libre, pero el estado se preserva. Y, ya sabes, cuando el modo es visible, los hijos reaparecen, los efectos se vuelven a montar y el estado está exactamente como lo dejaste.

Así que pensemos en tres casos de uso poderosos. Primero, puedes pensar en nuestro ejemplo de pestañas del pasado que mencioné, donde tienes, ya sabes, un formulario de tres pasos. Luego, si vas de un lado a otro, pierdes todos los datos. Correcto. Así que puedes ver aquí, usarlo en este caso sería muy interesante. Aquí, como puedes ver, tenemos el antes, que es bastante malo. Tenemos la condición de renderizado y terminamos perdiendo todo el estado. Si aplicamos la misma estrategia que mostré antes aquí, podrás evitar todas esas cosas y mantener el estado. Así que si el usuario va de la pestaña A a B y luego de B a A nuevamente, será básicamente lo mismo que antes.

Otro ejemplo muy interesante, y aquí es uno de los más poderosos, es el pre-renderizado. Solo imagina que, ya sabes, puedes tener control sobre el modo de la Activity API para determinar si vas a comenzar a cargar algunos datos, algunos CSS, quiero decir, imágenes en segundo plano. Así que, por ejemplo, en nuestro flujo de reserva, mostramos un calendario con muchos espacios y horarios. Así que aquí, si el usuario quiere, ya sabes, confirmar, tendremos que ir paso a paso, como cargando la página de confirmación y luego cuando el usuario hace clic, establecemos el paso. Y sabes, esto lleva tiempo y sabemos que cada milisegundo cuenta. Así que aquí, dependiendo de la cantidad de datos que estamos tratando de recopilar, puede llevar una eternidad y puede ser muy malo para el usuario.

Una mejor opción es poder controlar y aprender de esas interacciones del propio usuario. Así que para nosotros, aprendimos que nuestros usuarios eran más propensos a reservar en las fechas que habían pasado el cursor. Así que si pasas el cursor, por ejemplo, sobre una fecha, ahora podríamos usar esta Activity API para pre-renderizar el espacio para ti. Así que cuando haces clic en reservar, la experiencia se sentirá instantánea. Así que como puedes ver aquí, advertimos previamente la obtención al pasar el cursor y luego cuando el usuario llega a la página de confirmación, se siente como si los datos ya estuvieran allí. Se siente instantáneo.

Imagina como el e-commerce está en Black Friday, cuán valioso puede ser esto para esos casos donde cada milisegundo cuenta.

Otro caso de uso muy importante que encontramos en la base de código fue la navegación hacia atrás. Así que poder mantener la posición de desplazamiento es muy importante. Aquí, en las vistas de menú, por ejemplo, tenemos una lista muy, muy larga que cada vez que tienes filtros y consultas y por qué no, dependiendo de la forma en que vayas a construir esta pantalla, si retrocedes, todo se reiniciará. Si vas y vienes, tendrás que volver a buscar a todos, tendrás que guardar tu estado, o tendrás que crear algunas capas persistentes, lo que puede traer mucho overhead a tu aplicación. Con la Activity API, tenemos control de los datos. Así que cuando un usuario va y viene, todos los datos se mantienen preservados. No tenemos que mostrar un spinner, no tenemos que refrescar, no hay parpadeo y la experiencia se siente instantánea. Así que eso es muy, muy valioso para nosotros.

Así que con nuestra base de código, notamos en resultados reales aquí que eliminamos 540 líneas de código y comenzamos a mantener dos hooks que teníamos internamente para controlar el estado, lo cual para nosotros era bastante importante. Entonces déjame mostrarte mi flujo paso a paso sobre cómo abordar esos cambios. Cómo abordo esos cambios cada vez que tenemos nuevas actualizaciones y cómo aprendo esas cosas y cómo llevo esas cosas a grandes bases de código. Así que primero me gusta medir las cosas. Y sabes, incluso me preparé para compartir, si quieres esto, por favor házmelo saber, cómo identificamos oportunidades en la propia base de código. Así que aquí, como puedes ver en esta charla, cada pequeña API que quiero adoptar, primero realizo algunos hallazgos con Grab en una base de código para tratar de identificar oportunidades. Así que ese es realmente mi primer consejo para ti. No tienes que hacerlo todo de una vez y puedes priorizar por relación de impacto. Así que aquí está la base de código en la que estoy trabajando, EU para mí, ¿verdad? Como vamos paso a paso por esas nuevas APIs. Así que encontramos muchas supresiones de enlaces, memorias, llamadas, renders condicionales. Y uso esto como una guía para entender cuánto impacto puedo hacer en una base de código con las nuevas APIs.

Así que otra cosa importante para nosotros es medir el éxito y entender dónde las cosas están funcionando y dónde no. Así que aquí, ya sabes, poder activar el compilador, por ejemplo, y verificar el rendimiento usando las herramientas que tenemos en DevTools. Es muy, muy importante revisar cada componente que ahora memorizas automáticamente y ver cómo interactúan entre sí, asegurarte de que están obteniendo los beneficios que intentas habilitar. Además, la calidad del código no es un muy buen indicador, como puedes ver para nosotros, después de habilitar el compilador, ejecutar esas verificaciones, asegurarnos de que no rompimos nada. Reducir la cantidad de líneas de código fue muy importante. Así que podemos hacer nuestras herramientas de AI mejores, más predecibles y consumir menos tokens. Y en general, creo que la experiencia de desarrollo, ya sabes, el tiempo para implementar nuevas características ahora, tenemos menos errores, y fue mucho más amigable para los nuevos miembros del equipo entender la base de código. Así que aquí hay un número real, como nuestro tiempo de revisión de PR se redujo en un 12%. He eliminado todos estos bullet plates, adoptando esas nuevas características, ya sabes, como dejamos de hacer preguntas, obviamente, como, oh, ¿por qué está este used memo aquí? ¿Qué está haciendo? Es incluso relevante o no, ya sabes, esa es una medida de mejora de la experiencia de desarrollo.

Y aquí, creo que es la parte que para mí es muy importante porque podrías preguntarme, oye, Vitor, ¿por qué tengo que aprender esas cosas nuevas? ¿Por qué no puedo simplemente, ya sabes, pedirle a AI que las haga? Así que primero que nada, para mí, es muy importante que no delegues tu cerebro a AI, porque especialmente para cambios que están más allá, digamos, de los modelos de entrenamiento, vas a aprender, vas a ver que cometen muchos errores y no están preparados. Pueden leer la documentación y puedes usar esto como memoria, pero no es tan efectivo como si ejecutaran ese modelo de entrenamiento dentro de él. Y con muchos ejemplos. Así que por favor, por favor, si te llevas algo de esta masterclass, no delegues tu cerebro a AI, porque sé que muchas personas están frustradas, ya sabes, siendo bombardeadas por AI todos los días, todo el tiempo. Está haciendo que nuestros cerebros se sientan muy estresados. Así que, ya sabes, ser bombardeado cognitivamente, es algo muy real. Así que ten cuidado con eso. Ya sabes, no delegues tu cerebro a AI. Y entiendo, ¿verdad? Como tengo dos confesiones para mí. Una, ya que yo mismo he desplegado código que no entendía completamente. ¿Verdad? Y estoy bastante seguro solo por estadísticas, si estás viendo esto. Tú también lo hiciste, porque, ya sabes, sabemos que la adopción de herramientas de AI es bastante alta, pero. La presión para entregar, para ser más rápido, también es bastante alta. Y, ya sabes, los humanos se convierten en el cuello de botella, pero tenemos que tomar el control de las cosas. Tenemos que tomar el control de esas cosas. Y solo podemos hacer esto aprendiendo y realmente entendiendo lo que estamos haciendo. Así que. Entiendo dónde estás ahora, porque empezamos a hacer, ya sabes, preguntas muy importantes. Pero lo más importante, no puedes depurar lo que no entiendes. ¿Verdad.

Y no hay manera de que yo, en un mundo que te ayude con eso. Así que. Sabes, probablemente como muchas, muchas personas, empiezo a tener una vida más estresante como desarrollador después de AI. Sabes, hay muchos beneficios. Hay muchas cosas buenas. No, pero hay muchas preguntas que nunca tuvimos que hacernos antes. Que ahora son tan relevantes, ¿verdad? Como estamos siendo bombardeados por cosas nuevas todos los días. Y entiendo que esto puede sentirse muy estresante, ¿verdad? Como ahora tenemos más personas contribuyendo a la base de código, sabes, a veces diseñadores, a veces PNs. Y ahora todos quieren ser desarrolladores. Todos se sienten empoderados para serlo, lo cual es algo genial, pero tenemos que ser muy cuidadosos, ¿verdad? Como vemos que cada vez más y más problemas de seguridad muy grandes están surgiendo más y más prácticamente cada día. Estamos siendo bombardeados por esas, como noticias que, sabes, como ahora React ya no es seguro. Así que es seguro, pero no tanto ya. Así que tenemos que estar atentos a esas cosas para evitar esos grandes errores. Así que necesitamos ser muy, muy, muy responsables. Por eso creo que sigue siendo muy importante que aprendamos esas cosas que entendemos y luego usemos esas herramientas a nuestro favor para hacer nuestro trabajo más fácil. Pero teniendo el control total.

Así que para finalizar, para darte una manera concreta de cómo abordar esas nuevas actualizaciones y sabes, cómo hacer tu base de código más agradable y adoptar esas nuevas APIs. Aquí está el paso a paso de nuevo. Así que puedes comenzar con el compilador de React. Es solo una línea de código para que, sabes, instales el plugin de ESLint, asegúrate de que todo esté allí y puedas ejecutar las verificaciones de salud. Y ya puedes ver que tus componentes pueden ir más allá de la memorización manual. No tienes que borrar todo. Solo puedes observar y luego dejar de escribir esos hooks de memorización. Luego, de impacto medio a alto, puedes comenzar a auditar tu base de código, sabes, para esas oportunidades donde puedes reemplazar cosas con el Activity API, usando ActionState, sabes, hacer tu base de código más agradable y también moverte de un modelo imperativo a uno declarativo.

Luego, con un alto esfuerzo, alto impacto, puedes comenzar a analizar cómo los usuarios están usando tu aplicación, dónde están las oportunidades para el renderizado parcial y estructurar componentes entre estáticos y dinámicos para poder, sabes, decir con este enfoque granular cuándo precargar algo, cuándo pre-renderizar algo y cómo controlas el flujo de obtención de datos. Y aquí para mostrarte esto en práctica, ¿verdad?, es esta pequeña aplicación que creé solo para controlar cómo quiero hacer esas actualizaciones a la base de código. Así que aquí estoy ejecutando todas esas verificaciones basadas en el script que te mostré antes, donde podemos identificar cada instancia de use memo, cada instancia de llamadas de supresión para el ESLint que podemos usar estas nuevas APIs y cada oportunidad para que yo adopte, por ejemplo, el Activity API también. Así que la forma en que te estoy mostrando es en realidad la forma en que estoy implementando mi base de código también. Así que espero que te guste. Fue muy divertido recopilar todo este conocimiento y poder compartirlo aquí contigo. Y si tienes alguna pregunta, házmelo saber.