Dela tillstånd och routning mellan remotes

Varje Module Federation-remote är en applikation som byggs och distribueras självständigt. Dess tillstånd (React useState, Context och Zustand stores) finns i dess eget JavaScript-modulscope. Host och remotes delar inte automatiskt tillstånd – du måste utforma delningen uttryckligen.

Den enklaste mekanismen för att dela tillstånd är URL:en: alla remotes kan läsa URL-parametrar, frågesträngar och hashvärden utan kommunikation mellan remotes. Det fungerar bra för huvudnavigeringens tillstånd, filtervärden och allt tillstånd som ska kunna bokmärkas och delas via en länk.

CustomEvents via webbläsarens EventTarget gör att remotes kan kommunicera utan direkta importer. En remote skickar ut window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })), och alla andra moduler (host eller andra remotes) lyssnar med window.addEventListener('cart:updated', handler). Ingen delad modul behövs.

Skapa en särskild ”state remote” som exponerar en Zustand- eller Jotai-store. Både hosten och andra remotes importerar från denna state remote och får samma store-instans – eftersom den är en delad singleton. Det är kraftfullt för komplext delat tillstånd (autentisering, varukorg och användarinställningar), men lägger till ett distributionsberoende.

Skalet (hosten) äger allt delat tillstånd och skickar det vidare till remotes som props eller via Context. Remotes tar emot callback-funktioner som onCartUpdate och navigate som props. Det håller tillståndet centraliserat i hosten, men kräver att hosten känner till remotes API:er – vilket skapar en tät koppling.

React Routers historik- och location-tillstånd tillhandahålls av en Router-komponent (BrowserRouter eller createBrowserRouter). Det måste finnas exakt en Router i en Module Federation-konfiguration – om varje remote placerar ut en egen Router skapas flera konkurrerande routingkontexter, vilket leder till navigeringskonflikter.

Den arkitektoniska regeln är: hosten (skalet) tillhandahåller routern. Remotes tar emot routingprops från hosten (eller läser direkt från URL:en). En remote ska aldrig skapa en egen BrowserRouter – den skulle hamna i konflikt med hostens Router och förstöra navigeringen i hela applikationen.

React Context-värden är kopplade till en specifik React-instans och ett specifikt Context-objekt. För att en Context ska fungera mellan host och remote måste båda importera samma Context-objekt från samma källa – vanligtvis den delade state remoten eller ett delat verktygspaket. React-singletonen säkerställer att samma Context fungerar i alla remotes.

I en ren Module Federation-arkitektur äger skalet (hosten) HTML-skalet, Router-providern, Auth-contexten, providern för tema och design tokens samt den globala navigeringen. Remotes äger innehållet i sina respektive funktionsområden. Skalet sammanfogar remotes i layouten utan att känna till deras implementeringsdetaljer.

Det största antipatternet i Module Federation är en tät koppling mellan host och remotes: hosten importerar typer från remoten, remoten importerar komponenter från hosten eller så delar de ett gemensamt npm-paket som båda måste uppdatera samtidigt. Dessa kopplingar motverkar syftet med självständig distribution.

Definiera uttryckliga kontrakt mellan host och remotes: vilka props en remote-komponent accepterar, vilka CustomEvents den skickar ut och vilka URL-parametrar den läser. Dokumentera dessa kontrakt som TypeScript-gränssnitt i ett delat types-paket. Då kan teamen utvecklas självständigt inom det överenskomna kontraktet.

Delning av tillstånd mellan Module Federation-remotes kan använda URL-tillstånd (enklast), CustomEvents (löst kopplade), en shared state remote (centraliserad store) eller tillstånd som hosten äger och skickar som props. Hosten måste äga den enda Router-providern – remotes ska aldrig skapa egna. Tydliga kommunikationskontrakt via TypeScript-gränssnitt håller teamen löst kopplade och möjliggör verkligt självständig distribution.