Zustand und Routing zwischen Remotes teilen

Jedes Module-Federation-Remote ist eine unabhängig erstellte und bereitgestellte Anwendung. Sein Zustand (React useState, Context, Zustand-Stores) befindet sich in seinem eigenen JavaScript-Modul-Scope. Host und Remotes teilen ihren Zustand nicht automatisch – Sie müssen diese gemeinsame Nutzung ausdrücklich konzipieren.

Der einfachste Mechanismus zur gemeinsamen Zustandsverwaltung ist die URL: Jedes Remote kann URL-Parameter, Query-Strings und Hash-Werte ohne Kommunikation zwischen den Remotes auslesen. Das eignet sich gut für den primären Navigationszustand, Filterwerte und jeden Zustand, der als Lesezeichen gespeichert und per Link geteilt werden können soll.

CustomEvents über das EventTarget des Browsers ermöglichen die Kommunikation zwischen Remotes ohne direkte Importe. Ein Remote löst window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })) aus, und jedes andere Modul (der Host oder ein anderes Remote) kann mit window.addEventListener('cart:updated', handler) darauf hören. Ein gemeinsames Modul ist nicht erforderlich.

Erstellen Sie ein eigenes "State-Remote", das einen Zustandsspeicher von Zustand oder Jotai bereitstellt. Sowohl der Host als auch andere Remotes importieren daraus und erhalten dieselbe Store-Instanz, da es sich um ein gemeinsam genutztes Singleton handelt. Das ist für komplexe gemeinsam genutzte Zustände (Authentifizierung, Warenkorb, Benutzereinstellungen) sehr leistungsfähig, fügt aber eine Bereitstellungsabhängigkeit hinzu.

Die Shell (der Host) verwaltet den gesamten gemeinsamen Zustand und übergibt ihn als Props oder über Context an die Remotes. Remotes erhalten Callbacks wie onCartUpdate und Navigationsfunktionen als Props. Dadurch bleibt der Zustand im Host zentralisiert, allerdings muss der Host die APIs der Remotes kennen – es entsteht eine enge Kopplung.

Der History- und Location-Zustand von React Router wird von einer Router-Komponente (BrowserRouter oder createBrowserRouter) bereitgestellt. In einer Module-Federation-Konfiguration darf es genau einen Router geben – würde jedes Remote einen eigenen enthalten, entstünden mehrere miteinander konkurrierende Routing-Kontexte, die Navigationskonflikte verursachen.

Die architektonische Regel lautet: Der Host (die Shell) stellt den Router bereit. Remotes erhalten Routing-Props vom Host oder lesen die URL direkt aus. Ein Remote sollte niemals einen eigenen BrowserRouter erstellen – er würde mit dem Router des Hosts in Konflikt geraten und die Navigation der gesamten Anwendung beeinträchtigen.

React-Context-Werte sind an eine bestimmte React-Instanz und ein bestimmtes Context-Objekt gebunden. Damit ein Context zwischen Host und Remote funktioniert, müssen beide dasselbe Context-Objekt aus derselben Quelle importieren – typischerweise aus dem gemeinsamen State-Remote oder einem gemeinsamen Utilities-Paket. Das React-Singleton stellt sicher, dass derselbe Context in allen Remotes funktioniert.

In einer sauberen Module-Federation-Architektur verwaltet die Shell (der Host) Folgendes: die HTML-Shell, den Router-Provider, den Auth-Context, den Theme-/Design-Token-Provider und die globale Navigation. Die Remotes verwalten den Inhalt ihrer jeweiligen Fachdomaine. Die Shell fügt die Remotes in das Layout ein, ohne ihre Implementierungsdetails zu kennen.

Das größte Module-Federation-Antimuster ist eine enge Kopplung zwischen Host und Remotes: Der Host importiert Typen aus dem Remote, das Remote importiert Komponenten aus dem Host oder beide teilen ein gemeinsames npm-Paket, das sie gleichzeitig aktualisieren müssen. Diese Kopplungen machen den Zweck unabhängiger Bereitstellungen zunichte.

Definieren Sie explizite Verträge zwischen Host und Remotes: die Props, die eine Remote-Komponente akzeptiert, die CustomEvents, die sie auslöst, und die URL-Parameter, die sie liest. Dokumentieren Sie diese Verträge als TypeScript-Interfaces in einem gemeinsamen Types-Paket. So können sich die Teams innerhalb des vereinbarten Vertrags unabhängig weiterentwickeln.

Wo sollte der React-Router-Provider (BrowserRouter) in einer Module-Federation-Architektur platziert werden?

Die gemeinsame Zustandsverwaltung zwischen Module-Federation-Remotes kann über den URL-Zustand (am einfachsten), CustomEvents (lose gekoppelt), ein gemeinsames State-Remote (zentraler Store) oder einen vom Host verwalteten und als Props übergebenen Zustand erfolgen. Der Host muss den einzigen Router-Provider verwalten – Remotes sollten niemals eigene Router erstellen. Klare Kommunikationsverträge über TypeScript-Interfaces halten die Teams voneinander unabhängig und ermöglichen echte unabhängige Bereitstellungen.