Współdzielenie stanu i routingu między zdalnymi aplikacjami

Każdy remote w Module Federation jest niezależnie kompilowaną i wdrażaną aplikacją. Jego stan (React useState, Context, magazyny Zustand) znajduje się w osobnym zakresie modułu JavaScript. Host i remotes nie współdzielą stanu automatycznie — udostępnianie trzeba zaprojektować jawnie.

Najprostszym mechanizmem współdzielenia stanu jest URL: każdy remote może odczytywać parametry URL, ciągi zapytań i wartości fragmentu bez komunikacji między remote'ami. Sprawdza się to dobrze w przypadku głównego stanu nawigacji, wartości filtrów oraz każdego stanu, który powinien nadawać się do dodania do zakładek i udostępnienia za pomocą linku.

CustomEvents za pośrednictwem obiektu EventTarget przeglądarki umożliwiają remote'om komunikację bez bezpośrednich importów. Remote wysyła zdarzenie za pomocą window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })), a dowolny inny moduł (host lub inny remote) nasłuchuje go za pomocą window.addEventListener('cart:updated', handler). Nie jest potrzebny żaden współdzielony moduł.

Należy utworzyć dedykowany zdalny moduł stanu, który udostępnia magazyn Zustand lub Jotai. Zarówno host, jak i inne remotes importują z tego modułu tę samą instancję magazynu — ponieważ jest on współdzielonym singletonem. To rozwiązanie dobrze sprawdza się w przypadku złożonego współdzielonego stanu (uwierzytelniania, koszyka i preferencji użytkownika), ale wprowadza zależność od wdrożenia.

Powłoka (host) zarządza całym współdzielonym stanem i przekazuje go do remote'ów jako props lub za pośrednictwem Context. Remotes otrzymują callbacki, takie jak onCartUpdate, a także navigate jako props. Dzięki temu stan pozostaje scentralizowany w hoście, ale host musi znać API remote'ów, co tworzy silne powiązanie.

Stan historii i lokalizacji React Routera jest udostępniany przez komponent Router (BrowserRouter lub createBrowserRouter). W konfiguracji Module Federation musi istnieć dokładnie jeden Router — umieszczenie go w każdym remote powodowałoby utworzenie wielu konkurujących kontekstów routingu, prowadząc do konfliktów nawigacji.

Reguła architektoniczna jest następująca: host (shell) udostępnia Router. Remotes otrzymują od hosta propsy związane z routingiem albo odczytują dane bezpośrednio z URL. Remote nigdy nie powinien tworzyć własnego BrowserRouter — kolidowałby on z Routerem hosta i zakłóciłby nawigację w całej aplikacji.

Wartości React Context są powiązane z konkretną instancją React i obiektem Context. Aby Context działał między hostem a remote'em, oba muszą importować ten sam obiekt Context z tego samego źródła — zazwyczaj ze współdzielonego modułu stanu lub pakietu współdzielonych narzędzi. Singleton React zapewnia, że ten sam Context działa we wszystkich remote'ach.

W przejrzystej architekturze Module Federation shell (host) odpowiada za: powłokę HTML, dostawcę Routera, kontekst Auth, dostawcę motywu i tokenów projektowych oraz globalną nawigację. Remotes odpowiadają za treści swoich domen funkcjonalnych. Shell składa remotes w ramach układu bez znajomości szczegółów ich implementacji.

Największym antywzorcem w Module Federation jest silne powiązanie hosta z remote'em: host importuje typy z remote'a, remote importuje komponenty z hosta albo oba korzystają ze wspólnego pakietu npm, który muszą aktualizować jednocześnie. Takie powiązania niweczą sens niezależnego wdrażania.

Należy zdefiniować jawne kontrakty między hostem a remote'ami: propsy przyjmowane przez komponent remote'a, CustomEvents, które wysyła, oraz parametry URL, które odczytuje. Kontrakty te należy udokumentować jako interfejsy TypeScript we współdzielonym pakiecie typów. Dzięki temu zespoły mogą rozwijać się niezależnie, przestrzegając uzgodnionego kontraktu.

Stan między remote'ami Module Federation można współdzielić za pomocą stanu URL (najprostsze rozwiązanie), CustomEvents (luźne powiązanie), współdzielonego modułu stanu (scentralizowany magazyn) lub stanu hosta przekazywanego jako propsy. Host musi zarządzać jednym dostawcą Routera — remotes nigdy nie powinny tworzyć własnych. Jasne kontrakty komunikacyjne w postaci interfejsów TypeScript pozwalają zachować niezależność zespołów i umożliwiają rzeczywiście niezależne wdrażanie.