Event Aggregator
Use Aurelia's Event Aggregator for lightweight pub/sub communication between components.
The Event Aggregator provides a lightweight pub/sub mechanism for communication between components in your Aurelia applications. This documentation covers the basics of using the Event Aggregator, along with several advanced use cases for cross-component communication.
Aurelia registers a singleton EventAggregator behind the IEventAggregator interface. Resolving that token gives you the shared broker, and events are dispatched synchronously within the current tick—if a handler does heavy work, offload it to a task queue to keep the UI responsive.
Before you start: Review dependency injection so you are comfortable resolving services into components.
Basic Usage
To use the Event Aggregator in Aurelia, inject the IEventAggregator interface into your component. One common pattern is to resolve it using the resolve function.
Injecting and Subscribing
import { ICustomElementViewModel, IEventAggregator, resolve } from 'aurelia';
export class MyComponent implements ICustomElementViewModel {
readonly ea: IEventAggregator = resolve(IEventAggregator);
bound() {
this.ea.subscribe('event-name', payload => {
// Handle the event payload
});
}
}Publishing Events
To publish an event with an optional payload, simply call the publish method. Any component subscribed to the event will receive the data.
Strongly typed events
Besides string channels you can publish concrete event classes and subscribe to their constructors. This keeps payloads type-safe and avoids name collisions.
One-time subscriptions
When a listener should run only once, use subscribeOnce so it disposes itself automatically after the first payload.
Disposing of Subscriptions
It is best practice to dispose of your subscriptions when a component is no longer active, typically in the unbinding lifecycle hook, to prevent memory leaks.
Advanced Scenarios for Cross-Component Communication
The Event Aggregator can be used in several advanced scenarios where components need to communicate in a decoupled manner.
Use Case #1: Parent/Child Communication
In this use case, a child component publishes an event (e.g., a form submission), and a parent component subscribes to that event.
Child Component (Publishing an Event)
Parent Component (Subscribing to the Event)
Use Case #2: Plugin with Internal Communication
Sometimes a plugin needs to communicate internally without affecting global event subscriptions. You can create a new instance of the Event Aggregator to scope these events locally.
Plugin Component (Internal Communication)
Service (Triggering the Event)
Use Case #3: Plugin with Both Internal and Global Communication
A plugin can require both local (plugin-scoped) event handling as well as listening to global events. In this scenario, inject two separate instances of the Event Aggregator.
Use Case #4: Extending the Event Aggregator
You may wish to extend the functionality of the Event Aggregator by wrapping or subclassing it. For example, the following implementation tracks every event for which a subscription was created.
Extended Event Aggregator Implementation
Using the Extended Event Aggregator
Always dispose of your subscriptions when they are no longer needed to prevent memory leaks.
Next steps
Reach for watching data when you need property-level reactions instead of app-wide events.
Combine the Event Aggregator with App tasks to publish startup and shutdown events.
For UI composition alternatives, look at dynamic composition.
Last updated
Was this helpful?