Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EventDispatcher] Subscribers vs Listeners #3987

Closed
ManInTheBox opened this issue Jul 1, 2014 · 4 comments
Closed

[EventDispatcher] Subscribers vs Listeners #3987

ManInTheBox opened this issue Jul 1, 2014 · 4 comments
Labels
actionable Clear and specific issues ready for anyone to take them. EventDispatcher good first issue Ideal for your first contribution! (some Symfony experience may be required)

Comments

@ManInTheBox
Copy link

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!

@stof
Copy link
Member

stof commented Jul 1, 2014

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)

@wouterj wouterj added the actionable Clear and specific issues ready for anyone to take them. label Dec 13, 2014
@wouterj wouterj added the good first issue Ideal for your first contribution! (some Symfony experience may be required) label May 1, 2015
@javiereguiluz
Copy link
Member

I've added a note comparing listeners and reviewers in #5377 See details: 8a1d73b

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

@javiereguiluz
Copy link
Member

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

@xabbuh xabbuh closed this as completed Dec 30, 2015
@TomasVotruba
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
actionable Clear and specific issues ready for anyone to take them. EventDispatcher good first issue Ideal for your first contribution! (some Symfony experience may be required)
Projects
None yet
Development

No branches or pull requests

6 participants