การจัดการการนำทางแบบซ้อนและข้ามแอป

In federated apps, the shell owns top-level routes while each micro frontend owns its own internal (nested) routes. Coordinating the two is the heart of MFE navigation.

A clear rule helps: the shell maps a route prefix to an MFE, and everything below that prefix belongs to the MFE.

The shell renders the MFE for a prefix and lets it handle the remaining path segment.

The MFE defines its own router scoped to its prefix, so it controls its sub-pages without the shell knowing about them.

Give the MFE router a basename matching its prefix so its links resolve correctly within the larger app.

Sometimes one MFE must send the user into another (e.g. cart linking to checkout). The challenge: it should not import the other MFE router directly.

The cleanest cross-app navigation just changes the URL. The shell router then mounts the right MFE — no direct coupling needed.

To avoid manual history hacks, the shell can expose a small navigate function that MFEs call, centralizing navigation logic.

All MFEs must respond to the same browser history. Using one history source (the browser History API) keeps the shell and every MFE router synchronized on back/forward.

Two MFEs claiming overlapping prefixes cause unpredictable rendering. Maintain a single registry of route prefixes to guarantee they never collide.

Combine nested routing with lazy loading: only fetch an MFE bundle when the user navigates to its prefix, keeping initial load small.

Test your nested-routing knowledge.

You learned nested and cross-app navigation:

• Shell owns prefixes; MFEs own nested routes
• Use basename to scope MFE routers
• Navigate across apps via URL or a shared service
• Share one browser history source
• Prevent prefix conflicts and lazy-load by route

Coordinated routing makes federated navigation feel seamless.