Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

pavsid's avatar

Firing events

Hi all, I've been creating some events, in particular subscribing events to listeners, and to fire the event i've been using the helper function event.

I noticed though that this function can take two arguments eventname and payload, as an alternative to simply calling event(new MyEvent($object)).

This kind of makes the MyEvent class redundant, as it is not instantiated, and the $object is passed directly into the handler, rather than the event itself.

Is there any pros and cons to doing it this way?

0 likes
6 replies
pmall's avatar

This kind of makes the MyEvent class redundant, as it is not instantiated, and the $object is passed directly into the handler, rather than the event itself.

What ? Elaborate please.

It is always the event object which is passed to the handler.

pavsid's avatar

Not if you are subscribing events, and firing the event in the format event('\App\PodcastPurchased', $podcast).

For example, here is my listener..

<?php

namespace App\Listeners;

use App\Events\PodcastPurchased;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Support\Facades\Mail;

class PodcastEventListener
{
    /**
     * Create the event listener.
     *
     * @return void
     */
    public function __construct()
    {
        //
    }

    public function onPodcastPurchased($event){

        // $event is actually an instance of $podcast 
    // if you fire the event with event('App\Events\PodcastPurchased', $podcast)
    // rather than event(new App\Events\PodcastPurchased($podcast))

    }

    /**
     * Register the listeners for the subscriber.
     *
     * @param  Illuminate\Events\Dispatcher  $events
     * @return array
     */
    public function subscribe($events)
    {
        $events->listen(
            'App\Events\PodcastPurchased',
            'App\Listeners\PodcastEventListener@onPodcastPurchased'
        );
    }
}

So, what's the point of creating the App\Events\PodcastPurchased class? I can even delete that class and it still works.

phildawson's avatar
    public function fire($event, $payload = [], $halt = false)
    {
        // When the given "event" is actually an object we will assume it is an event
        // object and use the class as the event name and this event itself as the
        // payload to the handler, which makes object based events quite simple.
        if (is_object($event)) {
            list($payload, $event) = [[$event], get_class($event)];
        }
    Event::listen('SomeUniqueString', function($param){
        return $param;
    });

    dd(Event::fire('SomeUniqueString', 'foo'));

For why you make a class

protected $listen = [
    'App\Events\PodcastWasPurchased' => [
        'App\Listeners\EmailPurchaseConfirmation',
        'App\Listeners\SomethingElseConfirmation',
    ],
];
event(new PodcastWasPurchased($podcast));
class PodcastWasPurchased extends Event
{
    public function __construct(Podcast $podcast)
    {
        $this->podcast = $podcast;
    }
}
class EmailPurchaseConfirmation
{
    public function handle(PodcastWasPurchased $event)
    {
        $event->podcast; //
    }
}
class SomethingElseConfirmation
{
    public function handle(PodcastWasPurchased $event)
    {
        $event->podcast; //
    }
}
Snapey's avatar

I'm a newbie to this, but isnt it the case that there could be several listeners for a single event?

I thinks this is what @phildawson is illustrating. If you go direct then there can only be one event listener but if you go to the handler you can always extend what happens when you fire the event in the future without going back to the original class that triggers the event.

Is that right? Sorry if I am confusing the terminology of events, event listeners and handler

pavsid's avatar

@Snapey yeh that's a good point, but I'd have thought you'll always be accessing $event->podcast, so what's the point of passing in the event? Maybe there are other properties in the $event object that might be useful? Also I guess passing in the event leads to a consistent approach, so the system won't break like when, as you say, you have several handlers for a single event

pmall's avatar

@pavsid don't overthink this the regular way of using event with laravel is to fire an event object encapsulating data. It changes nothing so it is better to stick to the conventions.

Please or to participate in this conversation.