Condividere stato e routing tra remoti

Ogni remote di Module Federation è un'applicazione compilata e distribuita in modo indipendente. Il relativo stato (React useState, Context, store Zustand) vive nel proprio ambito del modulo JavaScript. L'host e i remote non condividono automaticamente lo stato: è necessario progettare esplicitamente questa condivisione.

Il meccanismo più semplice per condividere lo stato è l'URL: qualsiasi remote può leggere i parametri dell'URL, le stringhe di query e i valori hash senza alcuna comunicazione tra remote. Funziona bene per lo stato della navigazione principale, i valori dei filtri e qualsiasi stato che debba poter essere salvato nei segnalibri e condiviso tramite link.

I CustomEvents, tramite l'EventTarget del browser, consentono ai remote di comunicare senza importazioni dirette. Un remote esegue window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })), mentre qualsiasi altro modulo (l'host o altri remote) ascolta con window.addEventListener('cart:updated', handler). Non è necessario alcun modulo condiviso.

Crei un "state remote" dedicato che esponga uno store Zustand o Jotai. Sia l'host sia gli altri remote importano da questo state remote e ottengono la stessa istanza dello store, perché si tratta di un singleton condiviso. È una soluzione potente per gli stati condivisi complessi (autenticazione, carrello, preferenze dell'utente), ma aggiunge una dipendenza dalla distribuzione.

La shell (l'host) possiede tutto lo stato condiviso e lo passa ai remote tramite props o Context. I remote ricevono callback come onCartUpdate e navigate come props. In questo modo lo stato rimane centralizzato nell'host, ma l'host deve conoscere le API dei remote, creando un accoppiamento stretto.

Lo stato di history e location di React Router viene fornito da un componente Router (BrowserRouter o createBrowserRouter). In una configurazione Module Federation deve esserci esattamente un Router: inserirne uno in ogni remote creerebbe più contesti di routing in competizione, causando conflitti di navigazione.

La regola architetturale è la seguente: l'host (la shell) fornisce il Router. I remote ricevono dall'host le props di routing (oppure leggono direttamente l'URL). Un remote non deve mai creare il proprio BrowserRouter: entrerebbe in conflitto con il Router dell'host e interromperebbe la navigazione dell'intera applicazione.

I valori di React Context sono legati a una specifica istanza di React e a un oggetto Context. Perché un Context funzioni tra host e remote, entrambi devono importare lo stesso oggetto Context dalla stessa origine, in genere dal remote dello stato condiviso o da un pacchetto di utility condivise. Il singleton React garantisce che lo stesso Context funzioni in tutti i remote.

In un'architettura Module Federation ben strutturata, la shell (l'host) possiede: la shell HTML, il provider del Router, il contesto Auth, il provider del tema/design token e la navigazione globale. I remote possiedono i contenuti dei rispettivi domini funzionali. La shell compone i remote nel layout senza conoscerne i dettagli di implementazione.

Il principale antipattern di Module Federation è l'accoppiamento stretto tra host e remote: l'host importa tipi dal remote, il remote importa componenti dall'host oppure entrambi condividono un pacchetto npm che devono aggiornare contemporaneamente. Questi accoppiamenti vanificano lo scopo della distribuzione indipendente.

Definisca contratti espliciti tra host e remote: le props accettate da un componente remote, i CustomEvents che invia e i parametri URL che legge. Documenti questi contratti come interfacce TypeScript in un pacchetto di tipi condiviso. In questo modo i team possono evolvere in modo indipendente, rispettando il contratto concordato.

Dove deve essere posizionato il provider di React Router (BrowserRouter) in un'architettura Module Federation?

La condivisione dello stato tra i remote di Module Federation può usare lo stato nell'URL (la soluzione più semplice), i CustomEvents (con accoppiamento debole), un remote per lo stato condiviso (store centralizzato) oppure lo stato gestito dall'host e passato tramite props. L'host deve gestire l'unico provider del Router: i remote non devono mai crearne uno proprio. Contratti di comunicazione chiari, definiti tramite interfacce TypeScript, mantengono i team indipendenti e consentono una vera distribuzione autonoma.