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

warpig's avatar
Level 12

Recommendation: where to start with events, observers, listeners (from laracasts)

I've never explored these topics in depth, but for the project I'm working on, they seem to be a daily necessity. From the outside, I see them as "notifications" and stuff... for example, when one makes a purchase on an eCommerce site and receive a confirmation email.

If all I need is to implement these kinds of features, where should I start? My project already uses a Stripe webhook, so I feel like that’s a good entry point but i feel like there are so many options like "events" "listeners" "observers"... and then on top of that I would love to display some kind of data within Filament....

Any recommendations?

0 likes
4 replies
LaryAI's avatar
Level 58

To get started with events, listeners, and observers in Laravel, it's important to understand the role each plays in your application:

  1. Events: These are simple classes that represent something that has happened in your application. For example, a PurchaseMade event could be fired when a user completes a purchase.

  2. Listeners: These are classes that handle the events. They contain the logic that should be executed when an event is fired. For example, a SendPurchaseConfirmationEmail listener could handle the PurchaseMade event to send an email to the user.

  3. Observers: These are used to listen to Eloquent model events, such as created, updated, or deleted. They are useful for handling model-specific logic.

Here's a step-by-step guide to get you started:

Step 1: Create an Event

You can create an event using the Artisan command:

php artisan make:event PurchaseMade

This will create a new event class in the App\Events directory.

Step 2: Create a Listener

Create a listener that will handle the event:

php artisan make:listener SendPurchaseConfirmationEmail

This will create a new listener class in the App\Listeners directory.

Step 3: Register the Event and Listener

In the EventServiceProvider located at app/Providers/EventServiceProvider.php, register your event and listener:

protected $listen = [
    \App\Events\PurchaseMade::class => [
        \App\Listeners\SendPurchaseConfirmationEmail::class,
    ],
];

Step 4: Fire the Event

You can fire the event in your application logic, for example, in a controller method after a purchase is made:

use App\Events\PurchaseMade;

public function completePurchase()
{
    // Logic to complete the purchase...

    // Fire the event
    event(new PurchaseMade($purchaseDetails));
}

Step 5: Handle the Event in the Listener

In your listener class, implement the handle method to define what should happen when the event is fired:

namespace App\Listeners;

use App\Events\PurchaseMade;

class SendPurchaseConfirmationEmail
{
    public function handle(PurchaseMade $event)
    {
        // Logic to send the confirmation email
        // Access event data using $event->purchaseDetails
    }
}

Step 6: Using Observers

If you want to use observers for model events, you can create an observer using:

php artisan make:observer PurchaseObserver --model=Purchase

Register the observer in the boot method of a service provider, typically AppServiceProvider:

use App\Models\Purchase;
use App\Observers\PurchaseObserver;

public function boot()
{
    Purchase::observe(PurchaseObserver::class);
}

In the observer, you can define methods like created, updated, etc., to handle model events.

Additional Resources

  • Laravel Documentation: The official Laravel documentation provides comprehensive guides on events and observers.
  • Laracasts: Check out Laracasts for in-depth video tutorials on these topics.

By following these steps, you should be able to implement events, listeners, and observers in your Laravel application effectively.

rdelorier's avatar

CAUTION!!

Do not let your application logic rely on events/listeners. I promise you it will be a tangled mess.

Keep the event/listener logic isolated to external notifications, ie: email, slack, zendesk etc.

The main reason comes down to how easy it is to queue these things. If you are relying on the result of the event to support your application logic, in my experience, it does not go well.

1 like
warpig's avatar
Level 12

@rdelorier thanks for the heads up. so you're saying i should only use events/listeners when i reeally need them.. if i need to let the user know about something it would be better to rely on emails and/or 3rd party integrations?

rdelorier's avatar

@warpig It's fine for things like notifications because that can just happen in the background. I was more just saying don't put application logic in things that could cause a race condition or would break other things if it fails.

I once worked somewhere that had used a lot of jobs to separate code just for isolation and when I updated the jobs to be queued everything went haywire and we had to revert and refactor a lot before we were able to try it again.

Please or to participate in this conversation.