Application events guide
A TypeScript event bus for loosely coupled modules
Use a small synchronous event bus when application modules need to exchange intent without importing or calling one another directly. White Label Mediator keeps event ownership explicit.
Publish intent without coupling modules
A publisher emits a named event without knowing which module will react. Subscribers own their reactions and can be added or removed without changing the publisher.
White Label Mediator follows EventEmitter ordering and works through the same contract in browser and Node.js environments.
import Mediator from 'white-label-mediator';
const mediator = new Mediator();
mediator.on('menu:state', ({open}) => console.log(open));
mediator.emit('menu:state', {open: true});Add typed events when the application has a vocabulary
An optional TypeScript event map can constrain event names and payload tuples at compile time without adding runtime validation or framework semantics.
The event names remain application-owned rather than being defined by the package.
type Events = {
ready: [name: string];
stopped: [];
};
const mediator = new Mediator<Events>();
mediator.emit('ready', 'Ada');Keep listener ownership explicit
The component that subscribes should keep the callback reference and remove its own listener during teardown. destroy() is for the event bus itself leaving the application, not for one component to clean up shared listeners.
Synchronous delivery also means a completed emit() call has already run the current listeners; asynchronous workflows should remain explicit in application code.
Use an event bus for cross-module intent, not everything
An event bus is useful when independent modules genuinely need to communicate without a direct dependency. Direct function calls are often clearer when the caller already owns the callee and no decoupling boundary is needed.
Keeping that distinction visible prevents the event bus from becoming an implicit global application API.