Sharing State and Routing Between Remotes

Each Module Federation remote is an independently built and deployed application. Its state (React useState, Context, Zustand stores) lives in its own JavaScript module scope. The host and remotes don't automatically share state — you must architect the sharing explicitly.

The simplest state sharing mechanism is the URL: any remote can read URL params, query strings, and hash values without any cross-remote communication. This works well for primary navigation state, filter values, and any state that should be bookmarkable and shareable via link.

CustomEvents via the browser's EventTarget allow remotes to communicate without direct imports. A remote dispatches window.dispatchEvent(new CustomEvent('cart:updated', { detail: cart })), and any other module (host or other remotes) listens with window.addEventListener('cart:updated', handler). No shared module needed.

Create a dedicated "state remote" that exposes a Zustand or Jotai store. Both the host and other remotes import from this state remote and get the same store instance — because it's a shared singleton. This is powerful for complex shared state (auth, cart, user preferences) but adds a deployment dependency.

The shell (host) owns all shared state and passes it down to remotes as props or via Context. Remotes receive callbacks like onCartUpdate and navigate as props. This keeps state centralized in the host but requires the host to know about remote APIs — creating tight coupling.

React Router's history and location state is provided by a Router component (BrowserRouter or createBrowserRouter). There must be exactly one Router in a Module Federation setup — placing it in each remote would create multiple competing routing contexts, causing navigation conflicts.

The architectural rule is: the host (shell) provides the Router. Remotes receive routing props from the host (or read from the URL directly). A remote should never create its own BrowserRouter — it would conflict with the host's Router and break navigation for the entire application.

React Context values are tied to a specific React instance and Context object. For a Context to work across host and remote, both must import the same Context object from the same source — typically the shared state remote or a shared utilities package. The React singleton ensures the same Context works across all remotes.

In a clean Module Federation architecture, the shell (host) owns: the HTML shell, the Router provider, the Auth context, the theme/design token provider, and global navigation. Remotes own their feature domain content. The shell composes remotes into the layout without knowing their implementation details.

The biggest Module Federation antipattern is tight host-remote coupling: the host imports types from the remote, the remote imports components from the host, or they share a common npm package that both must update simultaneously. These couplings defeat the purpose of independent deployment.

Define explicit contracts between host and remotes: the props a remote component accepts, the CustomEvents it dispatches, and the URL params it reads. Document these contracts as TypeScript interfaces in a shared types package. This allows teams to evolve independently within the agreed contract.

Where should the React Router provider (BrowserRouter) be placed in a Module Federation architecture?

State sharing across Module Federation remotes can use URL state (simplest), CustomEvents (loosely coupled), a shared state remote (centralized store), or host-owned state passed as props. The host must own the single Router provider — remotes should never create their own. Clear communication contracts via TypeScript interfaces keep teams decoupled and enable true independent deployment.