The No Frills Frontend Migration Survival Guide

Hola a todos. Gracias por acompañarme. Estoy realmente emocionado de hablar sobre algo que cada desarrollador front-end eventualmente enfrenta: las migraciones. No del tipo en el que movemos TypeScript y otra herramienta ligera. Me refiero a esas grandes. Las que te hacen cuestionar cada decisión arquitectónica que alguna vez tomaste. Sabes de lo que estoy hablando.

Las migraciones front-end pueden ser brutales. Nunca hay un buen momento para hacerlas. Estás equilibrando entre características de plazo, código antiguo y nuevos frameworks. Todo mientras intentas evitar romper la producción. Y sin embargo, las migraciones son inevitables, porque el mundo del front-end evoluciona rápido. React, Angular, Vue, todos han cambiado dramáticamente en solo unos pocos años.

Así que la pregunta no es si deberíamos migrar. Es cómo sobrevivimos a ello. Mi nombre es Adar Geva, y soy el cofundador y CTO de MyApp.dev. Un conjunto de herramientas que ayuda a los equipos a conectar y controlar interfaces de usuario remotas y micro front-ends más fácilmente. Pasé los últimos años ayudando a equipos a modernizar grandes sistemas front-end sin detener el desarrollo. He visto todo tipo de historias de migración, los grandes estallidos, la reescritura gradual y todo lo demás.

En esta charla, quiero despojarme de las palabras de moda y darte una guía de supervivencia sin adornos. Un modelo mental simple de cómo pensar sobre las migraciones front-end. Veremos el tipo principal de migraciones que puedes hacer, cuándo cada una de ellas tiene sentido y las compensaciones de las que nadie te advierte. Y luego exploraremos cómo los componentes web pueden realmente cambiar el juego aquí. No son solo una API de navegador. Pueden ser un puente entre sistemas antiguos y nuevos. Si alguna vez soñaste con ejecutar React junto a uno de Angular sin volverte loco, esta parte es para ti. Probablemente notaste que la palabra migración se usa para muchas cosas diferentes. Pero no todas las migraciones son iguales. Pasar de Angular a React no es lo mismo que reemplazar bibliotecas. Y ninguna de esas es como cambiar tu sistema de construcción de Webpack a Vite. Cada una de esas toca capas totalmente diferentes de tu stack y viene con sus propios riesgos y estrategias.

Las migraciones de frameworks suelen tratar sobre reescribir arquitecturas. Las migraciones de bibliotecas tratan sobre refactorizar patrones de uso. Y las migraciones de infraestructura, esas tratan sobre cambiar el suelo sobre el que estás parado. Así que antes de lanzarte a la migración, necesitas entender qué tipo de migración estás realmente haciendo, porque la estrategia correcta depende completamente del tipo.

En la charla de hoy, nos vamos a centrar principalmente en la migración de frameworks y la migración de infraestructura. Así que una vez que sabemos qué tipo de migración estamos haciendo, la siguiente pregunta es cómo lo hacemos. Y aquí, realmente hay dos estrategias principales. El big bang y la migración gradual.

Un big bang es el cambio atómico claro. Un día estamos en Angular, al siguiente en React. Es elegante en teoría, pero arriesgado en la práctica. Obtenemos una base de código limpia, pero lo pagamos con tiempo de inactividad, largas pausas, desajustes de comportamiento o UI, y mucha presión. El enfoque gradual, por otro lado, nos permite migrar pieza por pieza.

Reduce el riesgo inmediato, pero crea estados de transición de larga duración. Dos sistemas coexisten.

Eso añade complejidad y mantenimiento, pero tu producto sigue avanzando. No hay un ganador universal. Todo se trata de equilibrar el riesgo, el tiempo y el mantenimiento para tu contexto.

Para la migración de frameworks e infraestructura, vamos a explorar una herramienta que creo que puede proporcionar una gran mitigación para esa complejidad. Una vez que estamos considerando la ruta gradual, todavía hay dos direcciones principales que podemos tomar. De afuera hacia adentro o de adentro hacia afuera.

El enfoque de afuera hacia adentro comienza desde la capa externa. Cosas como el diseño de la aplicación, el enrutamiento y la estructura a nivel de página. Primero reconstruyes el marco y luego vuelves a integrar tus componentes antiguos a medida que avanzas. Te da control sobre la arquitectura, pero es más difícil integrar secciones no terminadas.

El enfoque de adentro hacia afuera invierte eso. Comienzas desde los componentes hoja, las pequeñas piezas aisladas que pueden ser fácilmente reemplazadas. Tu capa existente y el enrutamiento permanecen igual mientras modernizas de abajo hacia arriba. Es más seguro para comenzar, pero retrasa los beneficios de la nueva arquitectura.

Cada camino intercambia control por seguridad, por lo que el correcto depende de la estabilidad de tu sistema y de cuánto cambio puede manejar tu equipo a la vez. Quiero centrarme en el enfoque de adentro hacia afuera, aunque las implementaciones técnicas que veremos son adecuadas para ambos. Así que, si miras alrededor, en realidad hay un montón de proyectos de código abierto tratando de facilitar la migración de frameworks.

Encuentras adaptadores que convierten React con Angular, envoltorios para Vue dentro de Svelte, y todo tipo de capas de puente ingeniosas. El problema es que la mayoría de ellos son muy específicos. Por lo general, apuntan de un framework a otro, a menudo vinculados a versiones particulares, y la mayoría no se mantienen activamente una vez que la moda pasa. Pero un problema mayor ni siquiera es el mantenimiento. Es el acoplamiento. Estas herramientas requieren que el lado del consumo conozca la implementación interna del componente que estás cargando. Terminas enseñando a tu aplicación React cómo hablar con los internos de Angular, y eso derrota completamente el propósito.

Lo que realmente queremos es un límite universal, una forma de consumir un componente sin importar qué frameworks lo construyeron. Y ahí es exactamente donde los Web Components comienzan a brillar. En la práctica, es mucho más simple de lo que podríamos pensar. Web Component es en realidad un conjunto de diferentes tecnologías, que nos permite crear elementos personalizados reutilizables con su funcionalidad encapsulada lejos del resto del código. Luego podemos utilizarlos dentro de cualquier aplicación web.

Y aquí está la parte interesante. El estándar de Web Component no es nuevo. La especificación V1 se finalizó hace mucho tiempo entre 2016 y 2018. Ha estado ahí, silenciosamente en el navegador, listo para que lo usemos. Pero los frameworks no estaban del todo listos para ello. Cada ecosistema tenía su propio modelo de renderizado, sus propias consultas. Y durante años, los Web Components dentro de React Vue se sintieron incómodos. Solo recientemente, las cosas realmente encajaron en su lugar. Como puedes ver aquí, React 19, Vue 3.2, Angular 16.2, ahora todos ofrecen soporte completo de primera clase para elementos personalizados. Eso es un gran avance, porque finalmente ha cerrado la brecha entre los componentes nativos del navegador y las interfaces de usuario impulsadas por frameworks. Y honestamente, eso es lo que hace que Web Component esté realmente listo para producción hoy, no hace seis años.

Bien, hablemos de lo que realmente son los Web Components. Hay tres bloques de construcción principales que necesitas conocer. Primero, shadow DOM. Le da a tus componentes su propio árbol DOM aislado, un pequeño mundo privado donde los estilos y el marcado pueden entrar y salir. Haría que un selector de fecha o un reproductor de video sean verdaderamente autónomos. Segundo, custom element. Estas son las APIs que te permiten definir tu propia etiqueta HTML, completa con callbacks de ciclo de vida y comportamientos personalizados. Una vez definidos, puedes colocarlos en cualquier lugar, React, Vue, Angular, e incluso HTML simple.

Y tercero, HTML template. Te permiten escribir fragmentos de marcado. En nuestro ejemplo, vamos a usar React para escribir realmente el HTML. Juntos, estos tres elementos forman la base de los Web Components, y todos se integran directamente en el navegador. Cada Web Component también tiene su propio ciclo de vida, similar en espíritu a lo que conocemos de frameworks como React. Comienza con el constructor, que se ejecuta cuando el elemento se crea por primera vez. Luego está el observable attribute, donde listas qué atributo debería desencadenar una actualización cuando cambian.

Cuando el elemento se añade al DOM, se dispara el connected callback, como lo hace el componente did mount de React. Si alguno de esos atributos cambia, obtienes el attribute change callback, para que puedas responder y volver a renderizar. También está el adopted callback, que se activa cuando el elemento se mueve a un nuevo documento. No es muy común, pero es bueno saberlo. Y finalmente, el disconnected callback. Tu gancho de limpieza cuando el elemento se elimina del DOM. Así que cuando miramos esos ganchos, está bastante claro. Una vez que los conectamos con el ciclo de vida de React, puedes pasar props dentro y fuera a través de esos puntos de entrada. Básicamente desbloqueamos la capacidad de usar React en todas partes, incluso dentro de un entorno que no sabe nada sobre React en sí.

Cuando importamos createRoot desde React DOM client, estamos usando la API de renderizado moderno de React, la que se introdujo en React 18. Nos permite crear cualquier árbol de componentes de React y renderizarlo en cualquier nodo DOM, incluido el Shadow DOM. Eso significa que podemos aislar completamente los estilos de la aplicación React y la estructura DOM, dándonos una verdadera encapsulación. Si lo hacemos dentro de un componente web y lo conectamos a su propio hook, tendremos un componente web potenciado por React.

Muy bien, vamos a sumergirnos en un ejemplo de código. Lo mantenemos simple, así que obtendremos las ideas principales. Paso uno, vamos a crear un componente web básico. Así que creamos una clase llamada HelloWorld. Extendimos el elemento HTML, implementamos el connected callback y pusimos alguna cadena en él. Luego, lo definimos a través de la API de custom element, llamando a define con la cadena, definiendo el nombre del custom element y la clase que lo implementó. Ahora tenemos un pequeño custom element, HelloWorld. Si lo pones en cualquier página HTML, se renderiza automáticamente.

Está completamente encapsulado, no se necesita framework, y sin dependencia, gracias al Shadow DOM. Ahora vamos a crear un componente de React básico. Así que creamos una función greeting, obteniendo un prop de nombre, y renderizando un low name desde React. Este es un componente estándar de React, funciona en cualquier lugar de la aplicación React, pero normalmente, React solo conoce sobre componentes de React. Ahora vamos a exponer este componente de React como un componente web.

Como puedes ver, podemos importar el create root desde React DOM client y crear un elemento greeting, extendiendo el elemento básico de HTML, implementar el connected callback, luego llamar al create root y llamar a root.render, renderizando el componente greeting directamente desde React, luego exponiéndolo como un componente web estándar. Ahora nuestro componente de React puede ser usado como un componente web. Se renderiza dentro de un custom element, completamente desacoplado de React en su página anfitriona.

Veamos cómo podemos pasar atributos como props. Así que como puedes ver aquí, podemos implementar el observe attribute y devolver con un elemento de cadena llamado name desde el observed attribute. Luego, en el connected callback, un attribute change callback, estamos llamando a una función interna de render. En el render, ahora podemos llamar al mismo código que usamos antes, pero leer el valor de name de la lista de atributos. Si no hay nada allí, usaremos un valor por defecto. Observe attributes, indica al componente con atributos a observar. Attribute change callback se dispara cada vez que un atributo cambia. Dentro de render, leemos el atributo y lo pasamos directamente como un prop de React.

Ahora en cualquier página HTML o incluso en una app de Angular, el elemento greeting es solo otro elemento en el DOM. No importa si es React bajo el capó. Simplemente funciona. Si disparamos un evento o props adicionales, Angular puede escuchar y responder naturalmente. Esto nos da un puente universal, permitiendo que todo el sistema nuevo coexista de manera segura y prepare el escenario para una migración fluida y de bajo riesgo, todo sin reescribir la aplicación completa. Esta es la parte donde desearía que tuviéramos otra hora juntos, porque aquí es donde las cosas realmente se ponen divertidas.