In a microfrontend shell, how does clicking a link inside one microfrontend (e.g. a 'View Order' link inside a Cart microfrontend that should open a route owned by a separate Orders microfrontend) trigger a client-side navigation instead of a full page reload?

## What a client-side cross-navigation preserves **Cross-microfrontend navigation** is the mechanism that lets a link rendered by one independently-deployed microfrontend take the user to a route owned by a completely different, independently-deployed microfrontend, without the browser doing a full page reload — which would defeat much of the point of a single-page microfrontend architecture: - shared state - avoided re-download of the shell/vendor bundle - instant perceived navigation ## The History API underneath Mechanically, the starting point is the browser's History API. `history.pushState(state, title, url)` changes the URL shown in the address bar and adds an entry to the session history stack without triggering a network request or a `load` event. Pair that with a listener on the `popstate` event (fired when the user clicks back/forward, or when something calls `history.back()`/`forward()`), and you have everything needed to build client-side routing: - intercept the intent to navigate - call `pushState` to update the URL - run whatever logic decides what to render for that URL ## Why a cross-boundary link is different In a single microfrontend app, that logic lives entirely inside the app. In a cross-microfrontend scenario, the complication is that the link's origin (the Cart MFE, which rendered `<a href="/orders/123">View Order</a>`) is not the same code that owns the target route (the Orders MFE). If Cart naively let the browser handle a normal anchor click, the browser would issue a full navigation/page load to `/orders/123`, which — depending on server config — either reloads the entire shell from scratch (losing any in-memory state, and re-downloading the shared vendor/shell bundle) or 404s if the server isn't set up to serve the shell for that path too. ## The standard fix — centralize the intent The standard fix is centralizing navigation intent-handling in the shell. Frameworks built for this (single-spa's root config with its `navigateToUrl` helper, or a custom implementation in a Module Federation shell): 1. attach a single global click listener on the document that intercepts clicks on same-origin anchor tags before the browser's default navigation fires; 2. calls `event.preventDefault()`, and instead calls the shell's own `pushState`-wrapping navigation function; 3. that function updates the URL, then re-runs the shell's route-matching against its route table (a data structure mapping path patterns to microfrontend 'owners,' e.g. `/cart/* -> cart-mfe`, `/orders/* -> orders-mfe`); 4. if the new path resolves to a different microfrontend than the one currently mounted, the shell unmounts the outgoing MFE (calling its framework-specific teardown — React's root.unmount(), Vue's `app.unmount()`, or whatever lifecycle hook the microfrontend framework mandates) and mounts the incoming one, injecting whatever route params it parsed from the new path. ## Why routing needs a single writer The reason this must be centralized rather than each MFE managing its own `pushState` calls is that the History API and its `popstate` event are global, per-document, single-writer resources — there's exactly one history stack per browser tab, and if two independently-deployed pieces of code both try to own routing decisions, you get race conditions: - duplicate or missing history entries - back-button behavior that goes to the wrong microfrontend - or two MFEs both trying to mount on the same URL This is the microfrontend-specific version of the general 'single source of truth' principle — for routing, the shell is that source of truth, and individual MFEs should treat top-level navigation as something they request (e.g. by calling a shell-provided `navigateTo(path)` function passed in as a prop/context) rather than something they perform unilaterally. ## The boundary teams get wrong A concrete production pattern: single-spa's root config registers each microfrontend with an `activeWhen` matcher (a path prefix or function) and exposes a shared `navigateToUrl(url)` utility that every registered microfrontend imports and calls for any navigation that might cross an ownership boundary, instead of using framework-native routing (React Router's `<Link>`, Vue Router's `<router-link>`) for those specific cross-boundary links — while still using framework-native routing internally for navigation that stays within one MFE's own territory (e.g. tabs within the Cart page). Getting this boundary right — 'is this a same-MFE navigation I can do myself, or a cross-MFE navigation I must delegate to the shell' — is one of the most common sources of subtle bugs in microfrontend routing: teams forget to route an internal `<Link>` through the shared navigation helper, and it works fine until the target route happens to belong to a different microfrontend, at which point the click either does nothing or does a full page reload.