การสื่อสารด้วยเหตุการณ์ DOM แบบกำหนดเอง

The browser already has a built-in pub/sub system: the DOM event model. Using it for MFE communication needs no library and works across any framework.

CustomEvent lets you create your own named events carrying a detail payload, dispatched on any DOM element including window.

Any micro frontend can broadcast an event on a shared target such as window. Others do not need a direct reference to the sender.

A consuming MFE subscribes with addEventListener and reads the payload from event.detail.

Namespace event names to avoid collisions, for example cart:add or auth:login. A shared naming convention is part of your communication contract.

When a micro frontend unmounts, remove its listeners to prevent memory leaks and duplicate handling.

For request/response style flows, one MFE dispatches a request event and another replies with a separate response event, keeping each direction explicit.

Native events are appealing because they are:

• Framework-agnostic
• Zero-dependency
• Familiar to all web developers
• Naturally decoupled (no shared references)

They also have downsides:

• No type safety on detail
• Easy to misspell event names
• Hard to trace who listens to what
• Not ideal for large or frequent payloads

To reduce mistakes, wrap dispatch and listen in a small typed module shared across MFEs, centralizing event names and payload shapes.

Custom DOM events shine for simple, occasional notifications between loosely coupled MFEs. For complex shared data, prefer a dedicated event bus or shared store.

You learned native event communication:

• CustomEvent carries data in detail
• Dispatch on window; listen with addEventListener
• Namespace names and clean up listeners
• Great for simple, decoupled notifications
• Wrap in a typed helper to avoid mistakes

DOM events are a zero-dependency MFE channel.