Copied to Clipboard
Stack
-
Vite 5 — fast HMR, no config to fight
-
React 18 + TypeScript 5 — strict mode on
-
MUI 6 with
@emotion/react — both the app shell and the "good case" in demo 2
-
Plain CSS / inline styles in demo 1 to mimic the Tailwind-utility divergence without dual tooling
Run it locally
npm install
npm run dev # Vite dev server on http://localhost:5173
npm run build # tsc -b + production build
npm run preview # serve the production build
Project layout
src/
├── main.tsx
├── App.tsx # tabbed shell wiring the six demos
├── theme.ts # canonical MUI theme + design-token contract
├── components/
│ ├── DemoSection.tsx # title + controls + takeaway wrapper
│ ├── FakeMfePane.tsx # bordered "microfrontend" frame
│ ├── ConsoleOutput.tsx # styled pseudo-DevTools for simulated errors
│ └── CodeBlock.tsx # static syntax-block component
└── demos/
├── DesignTokenDrift.tsx
├── SharedThemeAdvantage.tsx
├── HttpLayerComparison.tsx
├── VersionHell.tsx
├── SharedStoreMinefield.tsx
└── DecisionMatrix.tsx
How the simulation works
-
Token drift / shared theme — Both MFE panes mount in the same React tree. The "isolated" demo passes a different token object to each pane; the "shared" demo wraps them in one
ThemeProvider. Same DOM, different sources of truth.
-
HTTP layer — Two in-memory client objects (one per MFE for "isolated", one global for "shared") with a fake
request() method. Buttons mutate client.token or client.broken and each pane logs what it observes.
-
Version hell — A static table of MFE versions plus a host record. Mounting compares them and pushes simulated React / MUI warnings into the
ConsoleOutput component.
-
Shared store — A tiny
FakeStore class with subscribe / set. Healthy mode: both MFE views point at the same instance. Drift mode: each points at its own instance, so increments don't cross.
The failure modes are real even if the runtime is staged — the same code paths exist in any Module Federation setup.
Credits
Article and demos by Ken Saadi.
LinkedIn · repo this example· show demo