Skip to content

PATTERN Cited by 1 source

Host-shell prop API for remotes

Problem

In a micro-frontend deployment, the remote bundles need to:

  • know who the user is (session, role, permissions),
  • see global app settings (theme, locale),
  • trigger portal-wide actions (logout rips session across all remotes; navigate to another remote's route; report an error the shell should surface globally),
  • occasionally hand data to another remote without hard-wiring a dependency.

If each team invents its own mechanism — a global event bus, cross-remote imports, direct DOM access, window globals — the shell becomes a pool of ad-hoc communication channels. Specifically:

  • An event bus couples remotes via string event names with no type safety; schema drift is silent.
  • Cross-remote imports break the independent-deploy property — remote A shipping is now gated on remote B's API.
  • Window globals are tamper-prone and cross-scope leaky.

Solution

Give every remote a single typed prop passed from the host shell when the shell mounts the remote's exposed component. The prop is the governed channel for all shell↔ remote communication:

// What the host passes to every remote
type PortalShellProps = {
  session: {
    userId: string;
    role: string;
    permissions: Record<string, { read: boolean; write: boolean }>;
  };
  settings: {
    theme: "light" | "dark";
    locale: string;
  };
  actions: {
    logout: () => void;
    navigate: (path: string) => void;
    reportError: (e: Error) => void;
  };
  // per-remote data hand-off
  data?: Record<string, unknown>;
};

Remotes only consume from the prop. They do not:

  • dispatch events on window,
  • import modules from other remotes directly,
  • read session data from cookies or storage themselves.

When a cross-cutting capability is needed (a new shell action, a new piece of session context), it is added to the prop type — one place, reviewed once, typed across all remotes.

Trade-offs

Pro - Typed contract. TypeScript + a shared PortalShellProps type catches drift at compile time. - Independence preserved. No cross-remote import dependency chain. - Single place to govern. New shell capabilities flow through one schema evolution, not N ad-hoc channels. - Deterministic portal-wide actions. Logout can definitely tear down every remote's session because the prop callback is the only way remotes talk to the shell.

Con - Prop bloat. Over time the prop accumulates every shell capability; needs periodic factoring. - Push-only. The prop is a one-way contract from shell to remote; the inverse (remote pushing state up to shell) requires callbacks, which are a second channel. - Versioning. Remote A expects session.role; the shell upgrades the prop to session.roles[]. Without a migration window, the remote breaks. The shell must maintain backward-compatible prop shapes across deploys. - Does not prevent remotes from cheating. Nothing stops a remote from also reading cookies; discipline still matters.

Seen in

  • sources/2024-10-16-zalando-building-a-modular-portal-with-webpack-module-federation — canonical wiki instance. Zalando's Logistics Portal passes "a prop to each application, which allows interaction with the portal and other applications. This prop serves as an interface for each micro frontend to communicate with the rest of the portal." The prop carries session info, global settings (theme / locale), portal-wide actions (logout ripples to all remotes; navigation requests; error handling), and data handoffs. Selected verbatim cases:
  • Session info — "Each micro frontend might need to access the currently logged-in user's session details, such as their role or permissions."
  • Logout broadcast — "If a user triggers a logout action from one micro frontend this action can be communicated to other applications through the shared prop, ensuring the entire session is closed and the user is logged out portal-wide."
  • Navigation — "If one application needs to trigger navigation to another part of the portal it can use the shared prop to request the portal to navigate the user to the appropriate page."
  • Error reporting — "Federated applications can pass errors (e.g., failed API calls) to the portal via the shared prop, and the portal can handle displaying a global error message or logging errors centrally."
Last updated · 550 distilled / 1,221 read