Symfony-docs: [EventDispatcher] Subscribers vs Listeners

Created on 1 Jul 2014  路  4Comments  路  Source: symfony/symfony-docs

Might be worth adding one note why should one choose event listener over subscriber and vice versa. As far as I know they act essentially the same if configured properly. For example an event subscriber is aware of subscribed events by implementing EventSubscriberInterface::getSubscribedEvents(). But event listeners can also listen on several events simply by adding more tags:

<service id="awesome_listener" class="Super\AwesomeListener">
    <tag name="kernel.event_listener" event="kernel.view" method="onKernelView" priority="1" />
    <tag name="kernel.event_listener" event="kernel.view" method="onKernelView" priority="2" />
    <tag name="kernel.event_listener" event="kernel.view" method="onKernelView" priority="3" />
    <tag name="kernel.event_listener" event="kernel.view" method="onKernelView" priority="4" />
    <!-- Any event type, handler method, as much as you want... -->
</service>

Also it might be a good idea to uniquely distinguish them all with Listener suffix (talking about class name). People seem to be confused what _listener_ is and what is _subscriber_ and they usually do things like ProfilerListener but also RequestSubscriber in their own code. And they say that is in official documentation which is true (look for StoreSubscriber) :)

Thanks!

EventDispatcher actionable good first issue

Most helpful comment

to be exact, a listener is a method.

The main advantage of subscribers (and the reason why Symfony switched to them in 2.1) is that it keeps the knowledge of the events in the class rather than in the service definition, making it easier to reuse the listener in other contexts (Silex for instance, which is why Symfony code was changed).

On the other hand, register listeners through the service definition gives more flexibility to the DI setup of the bundle (allowing to add the tag conditionally based on the config for instance)

All 4 comments

to be exact, a listener is a method.

The main advantage of subscribers (and the reason why Symfony switched to them in 2.1) is that it keeps the knowledge of the events in the class rather than in the service definition, making it easier to reuse the listener in other contexts (Silex for instance, which is why Symfony code was changed).

On the other hand, register listeners through the service definition gives more flexibility to the DI setup of the bundle (allowing to add the tag conditionally based on the config for instance)

I've added a note comparing listeners and reviewers in #5377 See details: https://github.com/symfony/symfony-docs/commit/8a1d73bd3357909579ffe9f0ae991834dd1b39ee

I've reused most of the @stof's comment, but please review the note. Thanks!

This issue can be closed as "fixed" as of this merge: https://github.com/symfony/symfony-docs/pull/5377/files#diff-6366c83737e1ec46c8aeee833de474c1R253

I'm sharing my thoughs on why chosing subscribers over listeners: Don't ever use Listeners

Was this page helpful?
0 / 5 - 0 ratings