Learn about how to subscribe to and handle router events for advanced navigation monitoring and application state management.
You can use the lifecycle hooks (instance and shared) to intercept different stages of the navigation when you are working with the routed components directly. However, if you want to tap into different navigation phases from a non-routed component, such as standalone service or a simple custom element, then you need to leverage router events. This section discusses that.
Router Event Types Overview
The router emits five distinct events that cover the complete navigation lifecycle:
Triggered when the browser location changes through user navigation (back/forward buttons) or hash changes.
interfaceLocationChangeEvent{readonlyid:number;// Unique navigation IDreadonlyurl:string;// New URLreadonlytrigger:'popstate'|'hashchange';// What caused the changereadonlystate:{}|null;// Browser history state}
NavigationStartEvent
Emitted before navigation execution begins, giving you a chance to prepare or cancel.
NavigationEndEvent
Fired when navigation completes successfully, providing final instruction details.
NavigationCancelEvent
Emitted when navigation is cancelled by lifecycle hooks (for example by returning false or returning a redirect instruction).
NavigationErrorEvent
Triggered when navigation encounters errors during execution.
Subscribing to Router Events
You can subscribe to router events in two ways: using the event aggregator or the type-safe IRouterEvents service (recommended).
Type-Safe Event Subscription with IRouterEvents
The recommended approach uses IRouterEvents for compile-time type safety and better developer experience:
Alternative: Event Aggregator Subscription
You can also use the standard event aggregator, though you lose TypeScript type safety:
Important: Using IRouterEvents provides type safety and IntelliSense support, making it the preferred approach.
Practical Use Cases and Examples
Leverage managed history state
The router stores a tiny object inside every browser history entry it creates. That object always contains an au-nav-id field (exported as AuNavId) so the router can determine whether a later popstate represents a backward or forward navigation. You can read and extend that managed state through the router events API.
Read managed state when navigation starts
The managedState payload is populated for both API-driven and browser-driven navigations, but only browser-triggered events will contain data you previously stored in history.state.
The au-nav-id key is requiredβalways merge existing state instead of overwriting it.
See Router state management for end-to-end scenarios, including persisting filters or scroll depth.
Store additional metadata per history entry
The router will emit the same metadata the next time that history entry is restored, allowing you to resume UI state in NavigationStartEvent or NavigationEndEvent handlers.
Global Loading Indicator
Show a loading spinner during navigation:
Analytics and Tracking Service
Track navigation events for analytics:
Error Handling and Recovery Service
Handle navigation errors gracefully:
Navigation State Management
Track and manage complex navigation states:
Best Practices for Router Events
Memory Management
Always dispose of event subscriptions to prevent memory leaks:
Performance Considerations
Debounce expensive operations in event handlers
Use singleton services for global event handlers
Unsubscribe when components are disposed
Avoid heavy computations in event handlers
Error Handling in Event Handlers
Always handle errors in event subscribers:
Debugging Router Events
Enable detailed logging for debugging:
Using Current Route for Simple Cases
For simple scenarios where you only need current route information without complex event handling, use ICurrentRoute:
See Current route for detailed information about the ICurrentRoute service.