Getting Started

Install via Composer: composer require zendframework/zend-eventmanager
Core concepts: EventManager, EventManagerInterface, ListenerAggregateInterface, and SharedEventManagerInterface
Minimal usage: Instantiate EventManager, attach a listener with attach(), trigger an event with trigger()
First use case: Decoupling logic in a service class (e.g., notify external systems when a user is created)
Start by reading src/EventManager.php and src/ListenerAggregateInterface.php for foundational APIs

Implementation Patterns

Use SharedEventManager to listen to events across multiple classes (e.g., UserCreated event triggered by both CLI and HTTP handlers)
Implement ListenerAggregateInterface for grouped, reusable listeners (cleaner than scattered attach() calls)
Prefer EventManagerInterface::triggerUntil() or trigger() with callback-based listeners to early-exit on conditions
Integrate with PSR-14 compatibility via wrapper classes (e.g., Zend\EventManager\PSR14\EventWrapper)
Use EventInterface (e.g., Event) to carry context (target object, name, params) between components
Centralize event names as constants (e.g., UserEvents::CREATED) to avoid typos

⚠️ Package is archived (no active development); consider migrating to psr/event-dispatcher for long-term support
Listener priority is critical: lower numbers run first; omitting priority defaults to 1
Shared listeners only fire if the triggering EventManager is configured with a SharedEventManagerInterface (common source of missing events)
Debug tip: Use EventManager::setIdentifiers() to scope events per context (e.g., per-request or per-object identity)
Beware circular references when listeners trigger new events—use getParams()/setParams() carefully or clone objects
Extension: Extend EventManager or use EventManagerSharedTrait in your base classes for consistent event behavior
For high-performance scenarios, avoid heavy logic in listeners—defer with queues or async workers where possible