Scaffold a Module Federation remote component consumer
58
73%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Use this skill when the task is to consume a remote Micro-Frontend (MFE) inside the host application. It covers two scenarios:
createRemoteComponent once at module level and render the result directly.LoadComponent helper to register and render a remote lazily, driven by a runtime MFEConfig object.Do not use this skill to create or modify the remote MFE itself. This skill only concerns the host-side consumer code.
| Placeholder | Usage |
|---|---|
MFE_NAME | The name field registered in the remote's module-federation.config.ts (e.g. customerPartyManagementMf). Must match exactly. |
MFE_URL | Full entry URL of the remote (e.g. https://remote.example.com/remoteEntry.js). |
COMPONENT_EXPOSE | The expose key defined in the remote config (e.g. ./PartySearchView, ./OptionPage). |
CONSUMER_NAME | PascalCase identifier for the local wrapper (e.g. PartySearchRemote, OptionPageRemote). |
CATEGORY_NAME | Subfolder under src/components where the consumer component lives (e.g. party, dashboard). |
All consumer components generated by this skill MUST strictly follow the Component Folder Pattern. Flat .tsx files are strictly forbidden.
Every new consumer must be generated inside its own PascalCase subfolder containing exactly:
[CONSUMER_NAME].tsx (The main component)types.ts or [CONSUMER_NAME].types.ts (Interfaces and types)index.ts (Barrel export)SDD_[CONSUMER_NAME].md (Software Design Document)The service file itself (src/api/services/module-federation/moduleFederationService.tsx) must never be modified. It is a read-only reference.
MFEConfigCreate the config object conforming to the MFEConfig interface. Place this constant inside the consumer's dedicated folder (either in the main .tsx or a separate config.ts inside the folder).
import type { MFEConfig } from '<RELATIVE_PATH_TO_SERVICE>/moduleFederationService';
export const MFE_NAME_Config: MFEConfig = {
mfe: 'MFE_NAME',
url: 'MFE_URL',
component: 'COMPONENT_EXPOSE',
};Use createRemoteComponent when the remote URL and component are known at build time:
import React from 'react';
import { createRemoteComponent } from '<RELATIVE_PATH_TO_SERVICE>/moduleFederationService';
import { MFE_NAME_Config } from './config'; // Or defined in the same file
const CONSUMER_NAME = createRemoteComponent(MFE_NAME_Config);
export const CONSUMER_NAMEWrapper: React.FC<Record<string, unknown>> = (props) => (
<React.Suspense fallback={<div>Loading CONSUMER_NAME…</div>}>
<CONSUMER_NAME {...props} />
</React.Suspense>
);
export default CONSUMER_NAMEWrapper;LoadComponent)Use LoadComponent when the MFEConfig is received at runtime (e.g. from an API response or a prop):
import React from 'react';
import { LoadComponent } from '<RELATIVE_PATH_TO_SERVICE>/moduleFederationService';
import type { MFEConfig } from '<RELATIVE_PATH_TO_SERVICE>/moduleFederationService';
import type { CONSUMER_NAMEProps } from './types';
export const CONSUMER_NAME: React.FC<CONSUMER_NAMEProps> = ({ config, ...rest }) => (
<LoadComponent
lazyElement={config}
loading={<div>Loading…</div>}
fallback={({ error }) => <div>Error: {error.message}</div>}
{...rest}
/>
);
export default CONSUMER_NAME;Inside the component's folder index.ts:
export { default as CONSUMER_NAME } from './CONSUMER_NAME';And add the folder to the category barrel (src/components/CATEGORY_NAME/index.ts):
export * from './CONSUMER_NAME';MFEConfig interface reference| Field | Type | Required | Description |
|---|---|---|---|
mfe | string | Yes | Remote name as registered in registerRemotes / module-federation.config.ts |
url | string | Yes | Full URL to the remote's remoteEntry.js |
component | string | Yes | Expose key (e.g. ./PartySearchView) |
name | string | No | Optional alias matching the backend model |
type | string | No | Optional type discriminator |
createRemoteComponent vs LoadComponent| Criterion | createRemoteComponent | LoadComponent |
|---|---|---|
| Config known at | Build time | Runtime |
| Registration | Automatic (idempotent) | Automatic (idempotent via createRemoteComponent internally) |
| Suspense | Manual wrapper required | Built-in |
| Fallback | Passed as option | Passed as prop |
| Use case | Static page wiring | Dynamic config from API / props |
moduleFederationService.tsx — it is a shared service layer.MFEConfig — do not call registerRemotes or loadRemote directly in consumer code.mfe must match exactly the name field in the remote's module-federation.config.ts.style={{ }} in consumer components — Tailwind className only.any.<RELATIVE_PATH_TO_SERVICE> dynamically — before generating any import, calculate the relative path from the consumer file's location to src/api/services/module-federation/. For example:
src/components/dashboard/OptionPageRemote/OptionPageRemote.tsx → ../../../api/services/module-federationsrc/components/party/search/PartySearchRemote/PartySearchRemote.tsx → ../../../../api/services/module-federation
Never hardcode an absolute path like src/api/services/.... Always emit a ../-based relative path.A correctly wired, type-safe MFE consumer: a component that registers the remote idempotently, loads it lazily via the service layer, and renders it with proper Suspense and error boundaries — ready for composition in the host application.
All consumer components generated by this skill must follow the Component Folder Pattern defined in the react-component skill. This means:
ConsumerName.tsx, ConsumerName.types.ts, index.ts, SDD_ConsumerName.md..tsx files are strictly forbidden.✅ src/components/dashboard/DashboardRemote/
DashboardRemote.tsx
DashboardRemote.types.ts
index.ts
SDD_DashboardRemote.md
❌ src/components/dashboard/DashboardRemote.tsx ← FORBIDDENSee react-component skill → Hard Rules section for the full specification.