Two micro-frontends, two React roots, one event contract
The two apps share no state, no context and no imports: only the cart:add event and its { name } payload, which is the whole contract. Unmounting one app leaves the other running. In production each mount function would come from a different deployment.
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
event cart:add { name: 'Tea' }
event cart:add { name: 'Coffee' }
Cart: 2 (Tea, Coffee)
catalog unmounted, cart still shows: Cart: 2 (Tea, Coffee)