Patterns & Architecture

A higher-order component (HOC) is a function that takes a component and returns a new component that renders the original one with something added: extra props, a check before rendering, data, a wrapper. The name mirrors higher-order functions — functions that take or return functions — and the idea is the same: withX(Component) returns an enhanced Component.

A good mental model is gift wrapping. The present (your component) doesn't change; the HOC wraps it in a layer that can decide whether to hand it over at all (an auth check), what to hand over with it (extra props), or what to show while you wait (a loading state). The person receiving it (the parent) only sees the wrapped box.

HOCs were the way to share behaviour between components before hooks (2015–2019): connect() from react-redux, withRouter from React Router 4/5, withStyles from Material-UI v4. You'll still meet them in older codebases and in interviews, and a few legitimately remain (React.memo is a HOC, and so is withErrorBoundary in react-error-boundary). For new shared logic, hooks have replaced them — see HOCs vs render props vs hooks.

From my notes — the extraProp example, step by step:

// Step 1: a normal component. It expects extraProp, but doesn't know where it comes from.
export const MessageComponent = ({ message, extraProp }) => {
  return (
    <div>
      <h2>{message}</h2>
      <p>{extraProp}</p>
    </div>
  );
};

// Step 2: the HOC. Takes a component, returns a new one that adds a prop.
export const withExtraProp = (WrappedComponent) => {
  return (props) => {
    const extraProp = "This is an extra prop from HOC!";
    return <WrappedComponent {...props} extraProp={extraProp} />;
  };
};

// Step 3: enhance once, at module level.
export const EnhancedMessageComponent = withExtraProp(MessageComponent);

// Step 4: render it. The caller passes only message.
export const App = () => {
  return (
    <div>
      <EnhancedMessageComponent message="Hello from HOC!" />
    </div>
  );
};

The authentication HOC

From my notes: "HOC great example" — check whether the user is signed in before rendering something. My notes hard-coded isAuthenticated = true with a comment; here it reads a real context so the example actually runs (both branches are tested):

import { createContext, useContext } from "react";

export const AuthContext = createContext({ user: null });

export const withAuth = (WrappedComponent) => {
  function WithAuth(props) {
    const { user } = useContext(AuthContext);
    if (!user) {
      return <div>Please log in to access this content.</div>;
    }
    // If authenticated, render the wrapped component with its original props
    return <WrappedComponent {...props} />;
  }
  WithAuth.displayName = `withAuth(${WrappedComponent.displayName || WrappedComponent.name})`;
  return WithAuth;
};

const SecretComponent = () => <h1>Secret Content: You can only see this if you are logged in.</h1>;
export const ProtectedComponent = withAuth(SecretComponent);

A data-fetching HOC

My notes listed "Fetching data HOC" as a real-world example but had no code for it. Here's one. It's configured first, then applied (withData(url)(Component)), the same two-step shape as react-redux's connect(mapState)(Component):

import { useEffect, useState } from "react";

export const withData = (url, propName = "data") => (WrappedComponent) => {
  function WithData(props) {
    const [state, setState] = useState({ loading: true, data: null, error: null });

    useEffect(() => {
      let cancelled = false;
      fetch(url)
        .then((res) => {
          if (!res.ok) throw new Error(`HTTP ${res.status}`);
          return res.json();
        })
        .then((data) => !cancelled && setState({ loading: false, data, error: null }))
        .catch((error) => !cancelled && setState({ loading: false, data: null, error }));
      return () => {
        cancelled = true;
      };
    }, []);

    if (state.loading) return <p>Loading…</p>;
    if (state.error) return <p role="alert">Failed: {state.error.message}</p>;
    return <WrappedComponent {...props} {...{ [propName]: state.data }} />;
  }
  WithData.displayName = `withData(${WrappedComponent.displayName || WrappedComponent.name})`;
  return WithData;
};

const UserNames = ({ users, title }) => (
  <section>
    <h2>{title}</h2>
    <ul>
      {users.map((u) => (
        <li key={u.id}>{u.name}</li>
      ))}
    </ul>
  </section>
);

export const UsersWithData = withData("/api/users", "users")(UserNames);

A render prop is a prop whose value is a function that returns JSX. The component that receives it does the work — fetching, tracking the mouse, managing open/closed state — and then calls the function to find out what to render, passing in the results. My notes put it well: it "does the core logic but doesn't decide how it would be displayed".

Mental model: the component is a chef who cooks but doesn't plate. It hands you the ingredients (data, state, callbacks) and you decide how they appear. HOCs push props into a component from outside; render props hand values out to whoever is rendering.

From my notes — DataFetcher, with two different renderings of the same data:

export const DataFetcher = ({ render }) => {
  const data = "Some fetched data"; // simulating fetched data
  return render(data);
};

export const App = () => {
  return (
    <div>
      <DataFetcher render={(data) => <h1>{data}</h1>} />
      <DataFetcher render={(data) => <p>{data}</p>} />
    </div>
  );
};

The more common modern spelling uses children as the function. Here the component has real state, which is what makes render props useful:

import { useState } from "react";

export function MouseTracker({ children }) {
  const [pos, setPos] = useState({ x: 0, y: 0 });
  return (
    <div data-testid="area" onMouseMove={(e) => setPos({ x: e.clientX, y: e.clientY })}>
      {children(pos)}
    </div>
  );
}

export const Coordinates = () => (
  <MouseTracker>{({ x, y }) => <p>The mouse is at {x}, {y}</p>}</MouseTracker>
);

From my notes — when to use render props:

1. Dynamic content rendering: the layout changes based on the component's data or state.
2. Encapsulating logic: animation, data fetching or event handling (like mouse movement) lives in one component; the consumer decides the rendering.
3. Multiple consumers with shared logic: several places need the same behaviour but render different things.

Where you still see render props in 2026: fallbackRender in react-error-boundary, row renderers in virtualised lists and table libraries, headless UI libraries (Downshift, React Aria's render-prop children), Formik's <Field>, and React Router 5's <Route render>.

HOCs, render props and custom hooks all answer the same question: how do two components share stateful logic without sharing UI? The difference is where the logic sits and how its values reach your component:

• A HOC wraps your component and pushes values in as props.
• A render prop component wraps your JSX and hands values out as function arguments.
• A custom hook runs inside your component and returns values as variables.

Here is one piece of logic — the current window width — written all three ways. The hook is the source of truth; the other two are built on it in a few lines, which is itself a good illustration of why hooks won:

import { useEffect, useState } from "react";

// 1. Custom hook (React 16.8+): the logic itself
export function useWindowWidth() {
  const [width, setWidth] = useState(() => window.innerWidth);
  useEffect(() => {
    const onResize = () => setWidth(window.innerWidth);
    window.addEventListener("resize", onResize);
    return () => window.removeEventListener("resize", onResize);
  }, []);
  return width;
}

// 2. HOC: pushes the value in as a prop
export const withWindowWidth = (Component) => {
  function WithWindowWidth(props) {
    const width = useWindowWidth();
    return <Component {...props} width={width} />;
  }
  return WithWindowWidth;
};

// 3. Render prop: hands the value out to a function
export function WindowWidth({ children }) {
  return children(useWindowWidth());
}

// Three consumers that render the same thing
export function HookLabel() {
  const width = useWindowWidth();
  return <p>hook: {width}</p>;
}
export const HocLabel = withWindowWidth(({ width }) => <p>hoc: {width}</p>);
export const RenderPropLabel = () => <WindowWidth>{(width) => <p>render prop: {width}</p>}</WindowWidth>;

const SafeWidget = withErrorBoundary(Widget, { fallback: <p>Oops</p> });
// Could this be written as const safe = useErrorBoundary(); inside Widget?

Compound components are a set of components that only make sense together and share hidden state: <Tabs>, <Tabs.List>, <Tabs.Tab>, <Tabs.Panel>. The parent owns the state (which tab is selected); the children read and update it through context, so the user of the API arranges the pieces however they like without wiring props between them.

The mental model is HTML's own <select> and <option>: you never tell an <option> whether it's selected or pass it an onChange; it just works because it's inside a <select>. Compound components give your own components that property. They're the backbone of headless UI libraries such as Radix UI, React Aria, Headless UI and Ark UI.

import { createContext, useContext, useId, useState } from "react";

const TabsContext = createContext(null);

function useTabs() {
  const ctx = useContext(TabsContext);
  if (!ctx) throw new Error("Tabs.* components must be used inside <Tabs>");
  return ctx;
}

export function Tabs({ defaultValue, children }) {
  const [value, setValue] = useState(defaultValue);
  const baseId = useId();
  return <TabsContext value={{ value, setValue, baseId }}>{children}</TabsContext>;
}

function List({ children }) {
  return <div role="tablist">{children}</div>;
}

function Tab({ value, children }) {
  const { value: selected, setValue, baseId } = useTabs();
  const isSelected = selected === value;
  return (
    <button
      role="tab"
      id={`${baseId}-tab-${value}`}
      aria-selected={isSelected}
      aria-controls={`${baseId}-panel-${value}`}
      onClick={() => setValue(value)}
    >
      {children}
    </button>
  );
}

function Panel({ value, children }) {
  const { value: selected, baseId } = useTabs();
  if (selected !== value) return null;
  return (
    <div role="tabpanel" id={`${baseId}-panel-${value}`} aria-labelledby={`${baseId}-tab-${value}`}>
      {children}
    </div>
  );
}

Tabs.List = List;
Tabs.Tab = Tab;
Tabs.Panel = Panel;

export function Settings() {
  return (
    <Tabs defaultValue="profile">
      <Tabs.List>
        <Tabs.Tab value="profile">Profile</Tabs.Tab>
        <Tabs.Tab value="billing">Billing</Tabs.Tab>
      </Tabs.List>
      <Tabs.Panel value="profile">Your name and photo</Tabs.Panel>
      <Tabs.Panel value="billing">Cards and invoices</Tabs.Panel>
    </Tabs>
  );
}

This pattern splits a feature into two kinds of component. A container knows how things work: it fetches data, holds state, talks to the store, and passes plain values and callbacks down. A presentational component knows how things look: it receives everything through props, holds at most UI state (is this dropdown open?), and has no idea where the data came from.

From my notes, under component design principles: separation of concerns ("each component should do one thing well; avoid mixing logic for different concerns like fetching data and UI rendering within the same component"), props-driven design (components customised through props, not internal changes) and keeping components as stateless as possible, lifting state to a parent when needed. Container/presentational is the classic way of applying those.

The mental model is a TV and its remote. The screen (presentational) just shows whatever it's given; the remote (container) decides what to show. You can test or redesign the screen without touching the remote.

import { useEffect, useState } from "react";

// Presentational: props in, markup out. Easy to test, easy to put in Storybook.
export function UserListView({ users, loading, error, onRefresh }) {
  if (loading) return <p>Loading…</p>;
  if (error) return <p role="alert">{error}</p>;
  return (
    <div>
      <button onClick={onRefresh}>Refresh</button>
      <ul>
        {users.map((u) => (
          <li key={u.id}>{u.name}</li>
        ))}
      </ul>
    </div>
  );
}

// Container: owns data and behaviour, renders the view.
export function UserListContainer({ fetchUsers }) {
  const [state, setState] = useState({ users: [], loading: true, error: null });
  const [version, setVersion] = useState(0);

  useEffect(() => {
    let cancelled = false;
    fetchUsers()
      .then((users) => !cancelled && setState({ users, loading: false, error: null }))
      .catch((e) => !cancelled && setState({ users: [], loading: false, error: e.message }));
    return () => {
      cancelled = true;
    };
  }, [fetchUsers, version]);

  return <UserListView {...state} onRefresh={() => setVersion((v) => v + 1)} />;
}

Composition over inheritance

My notes asked "What's the meaning of composition over inheritance??" and answered it: a component is "flexible and generic — doesn't care what is being passed to it, either through props or children". React has no component inheritance in practice; you build bigger components by putting smaller ones inside each other and by passing JSX into slots. The Modal from my notes (typed, as it was written):

import type { FC, ReactNode } from "react";

type ModalProps = {
  header: ReactNode;
  body: ReactNode;
  footer: ReactNode;
};

export const Modal: FC<ModalProps> = ({ header, body, footer }) => {
  return (
    <div className="modal">
      <div className="modal-header">{header}</div>
      <div className="modal-body">{body}</div>
      <div className="modal-footer">{footer}</div>
    </div>
  );
};

export const App = () => (
  <Modal header={<h2>Modal Title</h2>} body={<p>This is the modal content</p>} footer={<button>Close</button>} />
);

My notes also composed a form from smaller reusable parts — <form><Input label="Username" /><Input label="Password" type="password" /><Button label="Submit" onClick={handleSubmit} /></form> — "smaller components like Input and Button are reusable and can be composed to create complex UIs without re-writing logic." More on slots and children in children and composition over inheritance.

React doesn't prescribe a folder structure, which is why "how would you structure a large React app?" is a favourite interview question. The answer that scales is group by feature, not by file type: everything for "checkout" — its components, hooks, API calls, state and tests — lives in one folder, and features talk to each other only through a small public API.

The mental model is a city of neighbourhoods. A small app can be one street sorted by kind (all components here, all hooks there). A large one needs neighbourhoods (features) with their own shops, a shared utility district (UI kit, helpers), and a city hall (the app shell: routing, providers) — and rules about who may build roads into whose neighbourhood.

From my notes: "How to design react projects (I mean their structure)", "Better diagram of react project structure — I LIKE THIS", "Tests can be like this", "Context folder can be broken down something like…" and "ENTERPRISE level apps structure". All five were diagrams (screenshots) that didn't survive into the text version of the doc, so I can't reproduce what they showed. The structures below are the standard ones those headings describe; compare them with the original diagrams if you have them.

Small app: group by type

src/
  components/      Button.tsx, Modal.tsx, Header.tsx
  pages/           HomePage.tsx, SettingsPage.tsx
  hooks/           useDebounce.ts, useLocalStorage.ts
  context/         AuthContext.tsx, ThemeContext.tsx
  services/        api.ts
  utils/           formatDate.ts
  App.tsx
  main.tsx

Medium to large app: group by feature

src/
  app/                    # the shell: wiring only
    App.tsx
    router.tsx
    providers.tsx         # QueryClientProvider, store, theme, auth
  features/
    auth/
      components/         LoginForm.tsx, LoginForm.test.tsx
      hooks/              useAuth.ts
      context/            AuthContext.ts, AuthProvider.tsx
      api/                login.ts
      index.ts            # public API: export { LoginForm, useAuth, AuthProvider }
    checkout/
      components/         CartSummary.tsx, PaymentForm.tsx
      hooks/              useCart.ts
      store/              cartSlice.ts
      api/                orders.ts
      index.ts
  shared/                 # used by many features, knows about none
    ui/                   Button.tsx, Modal.tsx, Spinner.tsx
    hooks/                useDebounce.ts
    lib/                  http.ts, formatDate.ts
  pages/                  # thin route components that compose features
    CheckoutPage.tsx
  main.tsx

Enterprise scale: a monorepo of apps and packages

repo/
  apps/
    web/                  # the customer-facing app (feature folders inside, as above)
    admin/                # back-office app
  packages/
    ui/                   # the design system / component library, versioned
    api-client/           # generated from OpenAPI or GraphQL schema
    config-eslint/        # shared lint rules, including import boundaries
    config-ts/            # shared tsconfig bases
  package.json            # workspaces
  turbo.json              # or nx.json: task graph, caching

Path aliases keep imports readable once folders are deep — @/features/auth instead of ../../../features/auth. With Vite, you declare the alias for the bundler and the same path for TypeScript:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  resolve: { alias: { "@": "/src" } },
});
// tsconfig.json: "compilerOptions": { "paths": { "@/*": ["./src/*"] } }

A component library (my notes call it an SDK of reusable frontend components) is a package of UI building blocks that several apps install and use — buttons, inputs, dialogs, tables — built once, documented once, versioned and published. It's how a company keeps ten products looking and behaving consistently.

The mental model: you are now writing an API, not a screen. Every prop is a public contract other teams depend on; changing it is a breaking change; your users will use the component in ways you didn't imagine. So library components lean hard on the design principles from my notes — props-driven, composable, as stateless as possible — and on boring packaging details that apps never think about.

From my notes, the key points:

• Component design: separation of concerns, props-driven design, keep components stateless where possible and allow external control ("state lifting").
• Composition: build complex UI by combining small components ("composition over inheritance").
• Structure of the library, styling ("choose between CSS Modules or CSS-in-JS (styled-components)"), theming ("if you need theming, styled-components would give you that"), and documentation with Storybook.
• Packaging an SDK: modular packaging with Webpack or Rollup, tree shaking so unused components aren't bundled, semantic versioning (major.minor.patch), and distribution via npm or a private registry.

A library-grade component

"Allow external control" is the subtle one. A library Toggle must work uncontrolled (it keeps its own state, the app passes defaultPressed) and controlled (the app owns the state via pressed + onPressedChange). A small hook handles both, the same way Radix and React Aria do it:

import { useState, type ComponentProps } from "react";

export function useControllableState<T>(controlled: T | undefined, defaultValue: T, onChange?: (value: T) => void) {
  const [internal, setInternal] = useState(defaultValue);
  const isControlled = controlled !== undefined;
  const value = isControlled ? controlled : internal;
  const setValue = (next: T) => {
    if (!isControlled) setInternal(next);
    onChange?.(next);
  };
  return [value, setValue] as const;
}

type ToggleProps = Omit<ComponentProps<"button">, "onChange"> & {
  pressed?: boolean;
  defaultPressed?: boolean;
  onPressedChange?: (pressed: boolean) => void;
};

export function Toggle({ pressed, defaultPressed = false, onPressedChange, onClick, className, ...rest }: ToggleProps) {
  const [isOn, setIsOn] = useControllableState(pressed, defaultPressed, onPressedChange);
  return (
    <button
      type="button"
      {...rest}
      aria-pressed={isOn}
      className={["ui-toggle", isOn && "ui-toggle--on", className].filter(Boolean).join(" ")}
      onClick={(e) => {
        onClick?.(e); // the app's handler runs first…
        if (!e.defaultPrevented) setIsOn(!isOn); // …and can cancel the toggle
      }}
    />
  );
}

Packaging: what makes a library tree-shakable

{
  "name": "@acme/ui",
  "version": "2.4.0",
  "type": "module",
  "exports": {
    ".": { "types": "./dist/index.d.ts", "import": "./dist/index.js" },
    "./styles.css": "./dist/styles.css"
  },
  "files": ["dist"],
  "sideEffects": ["**/*.css"],
  "peerDependencies": { "react": "^19.0.0", "react-dom": "^19.0.0" },
  "devDependencies": { "react": "^19.3.0", "react-dom": "^19.3.0", "typescript": "^7.0.0", "vite": "^8.0.0" },
  "publishConfig": { "registry": "https://npm.acme.internal/" }
}

Updating my notes on tooling: they mention Webpack or Rollup for packaging. Rollup is still underneath most library builds, but in 2026 you'd usually reach for a wrapper — Vite's library mode, tsdown / tsup, or Rslib — which output ESM plus type declarations with a few lines of config. Webpack is rarely used for libraries now.

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  build: {
    lib: { entry: "src/index.ts", formats: ["es"], fileName: "index" },
    rollupOptions: { external: ["react", "react-dom", "react/jsx-runtime"] },
  },
});

Styling and theming the library

Correcting my notes slightly: they suggest styled-components if you need theming. That was the standard answer in 2020, but two things changed. Runtime CSS-in-JS doesn't work in React Server Components and adds style-injection work to every render, and styled-components entered maintenance mode in 2025 (its maintainer announced no new features). For a library today the common choice is plain CSS or CSS Modules with CSS custom properties for theming — they work in every framework, including Server Components — or a zero-runtime tool like vanilla-extract or Panda CSS.

:root {
  --ui-color-accent: #2563eb;
  --ui-radius: 6px;
}
[data-theme="dark"] {
  --ui-color-accent: #60a5fa;
}
.ui-toggle {
  border-radius: var(--ui-radius);
  border: 1px solid var(--ui-color-accent);
}
.ui-toggle--on {
  background: var(--ui-color-accent);
  color: white;
}

Storybook is a workshop for UI components: a separate dev app where every component is shown in isolation, in every state you care about (primary, disabled, loading, error, long text), with controls to change its props live. Each of those states is a story. My notes put it simply: "Let's say you have a button — you create a storybook for it, for visual testing and looking at it."

The mental model: stories are examples that double as tests and docs. The same "disabled button" story is a page a designer reviews, a documentation entry generated from the component's props, an interaction test that clicks it, and a screenshot that a visual-regression tool compares on every PR. For a component library it's the documentation site (my notes: "Documenting library: Storybook").

Stories are written in Component Story Format (CSF): a default export describing the component, and named exports for each story. This is the CSF 3 format for Storybook 10 (the current major in 2026) with the React + Vite framework. Storybook isn't installed in my sandbox, so this file wasn't executed; it follows the official docs' format exactly.

import type { Meta, StoryObj } from "@storybook/react-vite";
import { expect, fn } from "storybook/test";
import { Toggle } from "./Toggle";

const meta = {
  component: Toggle,
  tags: ["autodocs"], // generate a docs page from the props and stories
  args: { children: "Bold", onPressedChange: fn() },
} satisfies Meta<typeof Toggle>;

export default meta;
type Story = StoryObj<typeof meta>;

export const Off: Story = {};

export const On: Story = { args: { defaultPressed: true } };

export const Disabled: Story = { args: { disabled: true } };

export const TogglesOnClick: Story = {
  play: async ({ canvas, userEvent, args }) => {
    const button = canvas.getByRole("button", { name: "Bold" });
    await userEvent.click(button);
    await expect(button).toHaveAttribute("aria-pressed", "true");
    await expect(args.onPressedChange).toHaveBeenCalledWith(true);
  },
};

What Storybook gives a team, beyond "looking at it":

• Development in isolation: build the error state of a component without breaking the backend to see it.
• Interaction tests: with the Vitest addon (npx storybook add @storybook/addon-vitest), every story becomes a Vitest test run in a real browser, play functions included.
• Visual tests: Chromatic (from the Storybook team) screenshots every story and flags pixel changes on each PR — the "visual testing" in my notes.
• Accessibility checks: the a11y addon runs axe on every story.
• Reuse in unit tests: composeStories from @storybook/react-vite turns stories into components you can render in React Testing Library, so test fixtures and stories don't drift apart.

import { composeStories } from "@storybook/react-vite";
import { render, screen } from "@testing-library/react";
import * as stories from "./Toggle.stories";

const { On, Disabled } = composeStories(stories);

test("On story starts pressed", () => {
  render(<On />);
  expect(screen.getByRole("button", { name: "Bold" })).toHaveAttribute("aria-pressed", "true");
});

test("Disabled story is disabled", () => {
  render(<Disabled />);
  expect(screen.getByRole("button")).toBeDisabled();
});

Micro-frontends apply the microservices idea to the browser: one product's frontend is split into several smaller apps, each owned, built and deployed independently by its own team, and composed into what the user sees as a single application. The checkout team can ship on Tuesday without waiting for the search team's release train.

The mental model is a shopping mall. Each shop (micro-frontend) has its own staff, stock and opening hours; the mall (the shell or host) provides the building, the corridors (routing and layout) and shared services (sign-in). Shoppers experience one place. The hard parts are the same as in a mall: shared rules (design system, versions), getting between shops (navigation and communication), and not letting one shop's flood (a crash) close the whole building.

My notes start with the architecture we had at work: "a combination of separate React web apps all in one mono repo". The apps used Redux and Redux-Saga to manage state and dispatch actions that ended up as GraphQL queries and mutations. GraphQL resolvers (which tell GraphQL how to find or change each piece of data) talked to an ESB — a wrapper around a message bus such as NATS or Kafka. On the other side of the bus, microservices listened for messages, did the actual work against existing services, and replied over the bus; the resolver got the response and GraphQL returned it to the React app. So the frontend was split into apps, and the backend into services behind a message bus.

There are three ways to compose the frontend pieces, all from my notes:

Client-side composition

From my notes, the host side of client-side composition — remote components loaded lazily:

// In the host app (from my notes)
const Header = React.lazy(() => import("headerApp/Header"));
const Footer = React.lazy(() => import("footerApp/Footer"));

// In the App component
<Suspense fallback={<div>Loading...</div>}>
  <Header />
  <MainContent />
  <Footer />
</Suspense>;

iframes and postMessage

From my notes, the iframe approach is just <iframe src="https://micro-frontend-1.com" title="Micro Frontend 1"> per micro-frontend. The work is in communication: frames share nothing, so they talk through window.postMessage, and every receiver must check event.origin, because any page can post a message to any window.

import { useEffect, useRef, useState } from "react";

const CART_ORIGIN = "https://cart.example.com";

export function IframeHost() {
  const frameRef = useRef(null);
  const [count, setCount] = useState(0);

  useEffect(() => {
    function onMessage(event) {
      if (event.origin !== CART_ORIGIN) return; // ignore messages from anyone else
      if (event.data?.type === "cart:updated") setCount(event.data.count);
    }
    window.addEventListener("message", onMessage);
    return () => window.removeEventListener("message", onMessage);
  }, []);

  function clearCart() {
    frameRef.current?.contentWindow?.postMessage({ type: "cart:clear" }, CART_ORIGIN);
  }

  return (
    <div>
      <p>Items in cart: {count}</p>
      <button onClick={clearCart}>Clear cart</button>
      <iframe ref={frameRef} src={`${CART_ORIGIN}/widget`} title="Cart micro-frontend" />
    </div>
  );
}

Server-side composition

Server-side composition happens before React is involved: a server or CDN assembles the page from fragments that each team serves. Edge Side Includes (ESI) on a CDN or Server Side Includes in Nginx are the classic mechanisms:

<body>
  <esi:include src="https://header.example.com/fragment" />
  <main><esi:include src="https://product.example.com/fragment?id=42" /></main>
  <esi:include src="https://footer.example.com/fragment" />
</body>

Module Federation (introduced in webpack 5, 2020) lets separately built and deployed apps share modules at runtime. A remote build exposes some modules (./Button) through a small manifest file, remoteEntry.js. A host build declares the remote by name and URL, and then imports from it like a package: import("RemoteApp/Button"). Both declare shared dependencies — React above all — so the page loads one copy that everyone uses.

The mental model is npm, but resolved at runtime instead of build time. With an npm package, the host gets the version it was built with; with a federated module, the host gets whatever the remote team deployed most recently, without rebuilding the host. That's the independent deployment micro-frontends promise — and the reason you need version discipline and error handling.

From my notes: "We used Webpack Module Federation in SMT / Command Center." Their walkthrough, step by step — remote first. (Neither this nor any config in this topic can run in my sandbox, which has no webpack or second server; they're checked against the official webpack and module-federation.io docs.)

const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");
const path = require("path");

module.exports = {
  entry: "./src/index.js",
  output: {
    publicPath: "http://localhost:3001/", // Remote app will run on port 3001
  },
  mode: "development",
  devServer: {
    port: 3001,
    contentBase: path.join(__dirname, "dist"),
    hot: true,
  },
  module: {
    rules: [{ test: /\.js$/, exclude: /node_modules/, use: "babel-loader" }],
  },
  plugins: [
    new ModuleFederationPlugin({
      name: "RemoteApp",
      filename: "remoteEntry.js",
      exposes: {
        "./Button": "./src/Button", // Expose the Button component
      },
      shared: {
        react: { singleton: true },
        "react-dom": { singleton: true },
      },
    }),
  ],
};

The host declares the remote and imports from it:

new ModuleFederationPlugin({
  name: "HostApp",
  remotes: {
    RemoteApp: "RemoteApp@http://localhost:3001/remoteEntry.js", // Load the remote entry from remote-app
  },
  shared: {
    react: { singleton: true },
    "react-dom": { singleton: true },
  },
});

import React from "react";

// Import the remote Button component
const RemoteButton = React.lazy(() => import("RemoteApp/Button"));

function App() {
  return (
    <div>
      <h1>Host App</h1>
      <React.Suspense fallback="Loading...">
        <RemoteButton />
      </React.Suspense>
    </div>
  );
}
export default App;

Correcting my notes' config for 2026

The notes' example is the classic 2020–2021 tutorial and still shows the concepts correctly, but several details are outdated or will bite in production:

• contentBase no longer exists: webpack-dev-server 4 replaced it with static (devServer: { static: path.join(__dirname, "dist") }). On webpack-dev-server 4+ (6 is current) the notes' config fails schema validation.
• Import the plugin from the public API: const { ModuleFederationPlugin } = require("webpack").container; rather than the internal path webpack/lib/container/… (which works, but isn't a documented entry point).
• Hard-coded publicPath only works on localhost. Use publicPath: "auto" so the remote works from whatever URL it's deployed to.
• The async boundary: the host's entry must not import React synchronously, or you get "Uncaught Error: Shared module is not available for eager consumption". The webpack docs' fix is a bootstrap file — index.js contains only import("./bootstrap"); and bootstrap.js contains the createRoot(...).render(<App />) code — so webpack can initialise the shared scope before React is evaluated. (The alternative, eager: true, bundles the shared module into the entry and is discouraged.)
• A remote that's down crashes the host. React.lazy rejects, and without an error boundary the error propagates to the root. Wrap every remote in its own boundary and Suspense (tested below).
• TypeScript doesn't know RemoteApp/Button. Either declare it (declare module "RemoteApp/Button" { const Button: React.ComponentType; export default Button; }) or let Module Federation 2.0 generate and download the remote's types (below).

Module Federation 2.0: @module-federation/enhanced

Module Federation is now developed by the module-federation organisation (with the Rspack team) as Module Federation 2.0. The package @module-federation/enhanced (2.x in 2026) provides drop-in plugins for webpack and Rspack, plus a runtime API. It adds an mf-manifest.json (richer than remoteEntry.js), automatic type generation and download for remotes, a Chrome devtools extension, and runtime plugins. From the official docs, the webpack setup:

module.exports = {
  name: "host",
  remotes: {
    provider: "provider@http://localhost:2004/mf-manifest.json",
  },
  shared: {
    react: { singleton: true },
    "react-dom": { singleton: true },
  },
};

const { ModuleFederationPlugin } = require("@module-federation/enhanced/webpack");
const mfConfig = require("./module-federation.config");

module.exports = {
  devServer: { port: 2000 },
  output: { publicPath: "http://localhost:2000/" },
  plugins: [new ModuleFederationPlugin(mfConfig)],
};

When the list of remotes isn't known at build time — a dashboard whose widgets come from a server-side registry, say — the runtime API registers and loads remotes from code:

import { createInstance } from "@module-federation/enhanced/runtime";
import React from "react";

const mf = createInstance({
  name: "mf_host",
  remotes: [{ name: "remote1", alias: "remote-1", entry: "http://localhost:3001/mf-manifest.json" }],
});

export const MyButton = React.lazy(() =>
  mf.loadRemote("remote1").then(({ MyButton }) => ({ default: MyButton })),
);

Loading a remote safely (tested)

The part of a federated host that can run anywhere is its failure handling. This RemoteSlot takes any loader — in the real host () => import("RemoteApp/Button") — and gives each remote its own Suspense and error boundary, with a retry:

import { lazy, Suspense, useState } from "react";
import { ErrorBoundary } from "react-error-boundary";

export function RemoteSlot({ load, name }) {
  const [attempt, setAttempt] = useState(0);
  // A new lazy component per attempt: React.lazy caches a rejected import forever.
  const [Remote, setRemote] = useState(() => lazy(load));

  function retry() {
    setRemote(() => lazy(load));
    setAttempt((a) => a + 1);
  }

  return (
    <ErrorBoundary
      resetKeys={[attempt]}
      fallbackRender={() => (
        <div role="alert">
          {name} is unavailable. <button onClick={retry}>Retry</button>
        </div>
      )}
    >
      <Suspense fallback={<p>Loading {name}…</p>}>
        <Remote />
      </Suspense>
    </ErrorBoundary>
  );
}