Skip to main content

All cases

Sharing React Components via CDN

Senior Frontend Engineer · 2025 · 2 min read

Validated CDN-delivered React UI so consumers can update shared components without npm version bumps across microfrontends.

Rejected path: Use Module Federation / webpack remotes (rejected for PoC: heavier ops surface)

Overview

Across the microfrontend platform, every shared UI change meant a new npm publish, version bumps in every consumer, and redeploys. This PoC checked whether we could serve live components from a CDN to React apps and, where needed, legacy stacks.

Problem

Updating a shared button or token meant coordinated version bumps and redeploys across teams. That slowed routine UI fixes.

Constraints

  • Had to work with existing React microfrontends without a full rewrite.
  • Deliverable as a compiled script URL on CDN, not npm.
  • Prefer a simple runtime approach over federation tooling.
  • Need a path for legacy non-React apps.

Architecture

First try: wrap remote React as Web Components. Complex props through the DOM were painful and clashed with internal libraries. Final approach: load plain React components from CDN in React apps, plus a thinner Web Component wrapper only for legacy.

Key Decisions

React components over CDN

Reasoning

Bundle, host, consume via script. Skips the npm update loop without adding federation complexity.

Alternatives considered
  • Use Module Federation / webpack remotes (rejected for PoC: heavier ops surface)
  • Keep npm publish + coordinated bumps (as today: too slow for token/UI fixes)

Skip Web Components for the React apps

Reasoning

Rich props through Custom Elements were awkward and conflicted with internal React libraries. Keep React as React.

Alternatives considered
  • Force all consumers through Custom Elements (rejected after prop/DOM friction)

Web Component wrapper for legacy only

Reasoning

Older apps needed the UI without adopting React. A simplified Custom Element was the escape hatch.

Alternatives considered
  • Leave legacy on frozen npm copies (rejected: dual maintenance forever)

Tech stack

  • React
  • TypeScript
  • Custom Elements API (Web Components)
  • CDN Delivery

Impact

Consumer update path CDN script vs npm bump + redeploy
React consumers Direct React-from-CDN (no Web Components wrapper)
Legacy path Thin Custom Element wrapper only
Federation tooling Avoided for PoC scope

Showed a path where core UI could ship to CDN and React consumers pick it up without a consumer redeploy. Also clarified when a Web Component wrapper is worth it (legacy) and when it is not.

Learnings

  • A script on a CDN is often enough when the goal is less process, not a new platform.
  • Web Components look universal, but forcing them into a React-heavy stack often costs more than they save.
  • A legacy escape hatch can protect old systems without hurting the modern path.

All cases