Compartir estado y enrutamiento entre remotos

Cada remote de Module Federation es una aplicación compilada y desplegada de forma independiente. Su estado (React useState, Context y stores de Zustand) reside en su propio ámbito de módulo JavaScript. El host y los remotes no comparten el estado automáticamente; debe diseñar explícitamente esta integración.

El mecanismo más sencillo para compartir el estado es la URL: cualquier remote puede leer los parámetros de URL, las cadenas de consulta y los valores hash sin comunicación entre remotes. Esto funciona muy bien para el estado de navegación principal, los valores de filtros y cualquier estado que deba poder guardarse en marcadores y compartirse mediante un enlace.

Los CustomEvents, mediante el EventTarget del navegador, permiten que los remotes se comuniquen sin imports directos. Un remote ejecuta window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })), y cualquier otro módulo (el host u otros remotes) escucha mediante window.addEventListener('cart:updated', handler). No se necesita ningún módulo compartido.

Cree un "state remote" dedicado que exponga un store de Zustand o Jotai. Tanto el host como los demás remotes importan desde este state remote y obtienen la misma instancia del store, ya que es un singleton compartido. Esto resulta muy potente para estados compartidos complejos (autenticación, carrito y preferencias del usuario), pero añade una dependencia de despliegue.

El shell (host) administra todo el estado compartido y lo pasa a los remotes mediante props o Context. Los remotes reciben callbacks como onCartUpdate y navigate mediante props. Esto mantiene el estado centralizado en el host, pero obliga al host a conocer las API de los remotes, lo que crea un acoplamiento estrecho.

El estado del historial y de la ubicación de React Router lo proporciona un componente Router (BrowserRouter o createBrowserRouter). En una configuración de Module Federation debe existir exactamente un Router; colocarlo en cada remote crearía varios contextos de enrutamiento en conflicto y provocaría problemas de navegación.

La regla arquitectónica es la siguiente: el host (shell) proporciona el Router. Los remotes reciben las props de enrutamiento del host o leen directamente la URL. Un remote nunca debe crear su propio BrowserRouter, ya que entraría en conflicto con el Router del host y rompería la navegación de toda la aplicación.

Los valores de React Context están vinculados a una instancia específica de React y a un objeto Context. Para que un Context funcione entre el host y un remote, ambos deben importar el mismo objeto Context desde el mismo origen, normalmente el remote de estado compartido o un paquete de utilidades compartido. El singleton de React garantiza que el mismo Context funcione en todos los remotes.

En una arquitectura limpia de Module Federation, el shell (host) administra el shell HTML, el proveedor del Router, el Context de autenticación, el proveedor del tema y de los tokens de diseño, y la navegación global. Los remotes administran el contenido de sus respectivos dominios funcionales. El shell integra los remotes en el diseño sin conocer los detalles de su implementación.

El antipatrón más grave de Module Federation es el acoplamiento estrecho entre el host y los remotes: el host importa tipos del remote, el remote importa componentes del host o ambos comparten un paquete npm que deben actualizar simultáneamente. Estos acoplamientos contradicen el objetivo del despliegue independiente.

Defina contratos explícitos entre el host y los remotes: las props que acepta un componente remoto, los CustomEvents que envía y los parámetros de URL que lee. Documente estos contratos como interfaces de TypeScript en un paquete de tipos compartido. Así, los equipos pueden evolucionar de forma independiente dentro del contrato acordado.

Para compartir el estado entre remotes de Module Federation puede usar el estado de la URL (la opción más sencilla), CustomEvents (con acoplamiento flexible), un remote de estado compartido (store centralizado) o un estado administrado por el host y pasado mediante props. El host debe administrar el único proveedor del Router; los remotes nunca deben crear uno propio. Los contratos de comunicación claros mediante interfaces de TypeScript mantienen desacoplados a los equipos y permiten un verdadero despliegue independiente.