Loading a remote at runtime and sharing one React (the module federation idea)
The host downloads code it has never seen at build time, checks a version promise, and passes its own React in so only one copy exists. If the remote's URL is down, the host shows a fallback instead of crashing: every remote is a network dependency that can fail. Click the stars: the remote's own state works.
When many teams share one frontend, a monorepo keeps several apps and packages in one repository with shared tooling, and micro-frontends split one product into separately deployed apps composed at runtime (for example with module federation); both enforce module boundaries, both have real costs, and most apps are better served by a well-structured single app first.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a mount(el, props) contract for a Newsletter micro-frontend that also supports updating props later (update(props)) and unmounting.
Write a pnpm-workspace.yaml and the package.json dependency that lets apps/web use a local @acme/ui package.
Explain it without notes
What is a monorepo and what problems does it solve for a React codebase?
What are micro-frontends, and when would you recommend them?
Explain module federation and why React must be shared as a singleton.
What are the costs of micro-frontends?
Preview
Console
Nothing logged yet.Expected console output
loaded remote reviews needs React 19 - host has 19.2.8
slot shows: Reviews for product 7: ★★★★