Laravel's events provide a simple observer implementation, allowing you to subscribe and listen for various events that occur in your application. Event classes are typically stored in the app/Events
directory, while their listeners are stored in app/Listeners
. Don't worry if you don't see these directories in your application, since they will be created for you as you generate events and listeners using Artisan console commands.
Events serve as a great way to decouple various aspects of your application, since a single event can have multiple listeners that do not depend on each other. For example, you may wish to send a Slack notification to your user each time an order has shipped. Instead of coupling your order processing code to your Slack notification code, you can raise an OrderShipped
event, which a listener can receive and transform into a Slack notification.
The EventServiceProvider
included with your Laravel application provides a convenient place to register all of your application's event listeners. The listen
property contains an array of all events (keys) and their listeners (values). You may add as many events to this array as your application requires. For example, let's add an OrderShipped
event:
/** * The event listener mappings for the application. * * @var array */ protected $listen = [ 'App\Events\OrderShipped' => [ 'App\Listeners\SendShipmentNotification', ], ];
Of course, manually creating the files for each event and listener is cumbersome. Instead, add listeners and events to your EventServiceProvider
and use the event:generate
command. This command will generate any events or listeners that are listed in your EventServiceProvider
. Events and listeners that already exist will be left untouched:
php artisan event:generate
Typically, events should be registered via the EventServiceProvider
$listen
array; however, you may also register Closure based events manually in the boot
method of your EventServiceProvider
:
use App\Events\PodcastProcessed; /** * Register any other events for your application. * * @return void */ public function boot() { Event::listen(function (PodcastProcessed $event) { // }); }
When registering event listeners manually, you may wrap the listener Closure within the Illuminate\Events\queueable
function to instruct Laravel to execute the listener using the queue:
use App\Events\PodcastProcessed; use function Illuminate\Events\queueable; use Illuminate\Support\Facades\Event; /** * Register any other events for your application. * * @return void */ public function boot() { Event::listen(queueable(function (PodcastProcessed $event) { // })); }
Like queued jobs, you may use the onConnection
, onQueue
, and delay
methods to customize the execution of the queued listener:
Event::listen(queueable(function (PodcastProcessed $event) { // })->onConnection('redis')->onQueue('podcasts')->delay(now()->addSeconds(10)));
If you would like to handle anonymous queued listener failures, you may provide a Closure to the catch
method while defining the queueable
listener:
use App\Events\PodcastProcessed; use function Illuminate\Events\queueable; use Illuminate\Support\Facades\Event; use Throwable; Event::listen(queueable(function (PodcastProcessed $event) { // })->catch(function (PodcastProcessed $event, Throwable $e) { // The queued listener failed... }));
You may even register listeners using the *
as a wildcard parameter, allowing you to catch multiple events on the same listener. Wildcard listeners receive the event name as their first argument, and the entire event data array as their second argument:
Event::listen('event.*', function ($eventName, array $data) { // });
Instead of registering events and listeners manually in the $listen
array of the EventServiceProvider
, you can enable automatic event discovery. When event discovery is enabled, Laravel will automatically find and register your events and listeners by scanning your application's Listeners
directory. In addition, any explicitly defined events listed in the EventServiceProvider
will still be registered.
Laravel finds event listeners by scanning the listener classes using reflection. When Laravel finds any listener class method that begins with handle
, Laravel will register those methods as event listeners for the event that is type-hinted in the method's signature:
use App\Events\PodcastProcessed; class SendPodcastProcessedNotification { /** * Handle the given event. * * @param \App\Events\PodcastProcessed * @return void */ public function handle(PodcastProcessed $event) { // } }
Event discovery is disabled by default, but you can enable it by overriding the shouldDiscoverEvents
method of your application's EventServiceProvider
:
/** * Determine if events and listeners should be automatically discovered. * * @return bool */ public function shouldDiscoverEvents() { return true; }
By default, all listeners within your application's Listeners directory will be scanned. If you would like to define additional directories to scan, you may override the discoverEventsWithin
method in your EventServiceProvider
:
/** * Get the listener directories that should be used to discover events. * * @return array */ protected function discoverEventsWithin() { return [ $this->app->path('Listeners'), ]; }
In production, you likely do not want the framework to scan all of your listeners on every request. Therefore, during your deployment process, you should run the event:cache
Artisan command to cache a manifest of all of your application's events and listeners. This manifest will be used by the framework to speed up the event registration process. The event:clear
command may be used to destroy the cache.
The
event:list
command may be used to display a list of all events and listeners registered by your application.
An event class is a data container which holds the information related to the event. For example, let's assume our generated OrderShipped
event receives an Eloquent ORM object:
<?php namespace App\Events; use App\Models\Order; use Illuminate\Broadcasting\InteractsWithSockets; use Illuminate\Foundation\Events\Dispatchable; use Illuminate\Queue\SerializesModels; class OrderShipped { use Dispatchable, InteractsWithSockets, SerializesModels; public $order; /** * Create a new event instance. * * @param \App\Models\Order $order * @return void */ public function __construct(Order $order) { $this->order = $order; } }
As you can see, this event class contains no logic. It is a container for the Order
instance that was purchased. The SerializesModels
trait used by the event will gracefully serialize any Eloquent models if the event object is serialized using PHP's serialize
function.
Next, let's take a look at the listener for our example event. Event listeners receive the event instance in their handle
method. The event:generate
command will automatically import the proper event class and type-hint the event on the handle
method. Within the handle
method, you may perform any actions necessary to respond to the event:
<?php namespace App\Listeners; use App\Events\OrderShipped; class SendShipmentNotification { /** * Create the event listener. * * @return void */ public function __construct() { // } /** * Handle the event. * * @param \App\Events\OrderShipped $event * @return void */ public function handle(OrderShipped $event) { // Access the order using $event->order... } }
Your event listeners may also type-hint any dependencies they need on their constructors. All event listeners are resolved via the Laravel service container, so dependencies will be injected automatically.
Sometimes, you may wish to stop the propagation of an event to other listeners. You may do so by returning false
from your listener's handle
method.
Queueing listeners can be beneficial if your listener is going to perform a slow task such as sending an e-mail or making an HTTP request. Before getting started with queued listeners, make sure to configure your queue and start a queue listener on your server or local development environment.
To specify that a listener should be queued, add the ShouldQueue
interface to the listener class. Listeners generated by the event:generate
Artisan command already have this interface imported into the current namespace, so you can use it immediately:
<?php namespace App\Listeners; use App\Events\OrderShipped; use Illuminate\Contracts\Queue\ShouldQueue; class SendShipmentNotification implements ShouldQueue { // }
That's it! Now, when this listener is called for an event, it will be automatically queued by the event dispatcher using Laravel's queue system. If no exceptions are thrown when the listener is executed by the queue, the queued job will automatically be deleted after it has finished processing.
If you would like to customize the queue connection, queue name, or queue delay time of an event listener, you may define the $connection
, $queue
, or $delay
properties on your listener class:
<?php namespace App\Listeners; use App\Events\OrderShipped; use Illuminate\Contracts\Queue\ShouldQueue; class SendShipmentNotification implements ShouldQueue { /** * The name of the connection the job should be sent to. * * @var string|null */ public $connection = 'sqs'; /** * The name of the queue the job should be sent to. * * @var string|null */ public $queue = 'listeners'; /** * The time (seconds) before the job should be processed. * * @var int */ public $delay = 60; }
If you would like to define the listener's queue at runtime, you may define a viaQueue
method on the listener:
/** * Get the name of the listener's queue. * * @return string */ public function viaQueue() { return 'listeners'; }
Sometimes, you may need to determine whether a listener should be queued based on some data that's only available at runtime. To accomplish this, a shouldQueue
method may be added to a listener to determine whether the listener should be queued. If the shouldQueue
method returns false
, the listener will not be executed:
<?php namespace App\Listeners; use App\Events\OrderPlaced; use Illuminate\Contracts\Queue\ShouldQueue; class RewardGiftCard implements ShouldQueue { /** * Reward a gift card to the customer. * * @param \App\Events\OrderPlaced $event * @return void */ public function handle(OrderPlaced $event) { // } /** * Determine whether the listener should be queued. * * @param \App\Events\OrderPlaced $event * @return bool */ public function shouldQueue(OrderPlaced $event) { return $event->order->subtotal >= 5000; } }
If you need to manually access the listener's underlying queue job's delete
and release
methods, you may do so using the Illuminate\Queue\InteractsWithQueue
trait. This trait is imported by default on generated listeners and provides access to these methods:
<?php namespace App\Listeners; use App\Events\OrderShipped; use Illuminate\Contracts\Queue\ShouldQueue; use Illuminate\Queue\InteractsWithQueue; class SendShipmentNotification implements ShouldQueue { use InteractsWithQueue; /** * Handle the event. * * @param \App\Events\OrderShipped $event * @return void */ public function handle(OrderShipped $event) { if (true) { $this->release(30); } } }
Sometimes your queued event listeners may fail. If queued listener exceeds the maximum number of attempts as defined by your queue worker, the failed
method will be called on your listener. The failed
method receives the event instance and the exception that caused the failure:
<?php namespace App\Listeners; use App\Events\OrderShipped; use Illuminate\Contracts\Queue\ShouldQueue; use Illuminate\Queue\InteractsWithQueue; class SendShipmentNotification implements ShouldQueue { use InteractsWithQueue; /** * Handle the event. * * @param \App\Events\OrderShipped $event * @return void */ public function handle(OrderShipped $event) { // } /** * Handle a job failure. * * @param \App\Events\OrderShipped $event * @param \Throwable $exception * @return void */ public function failed(OrderShipped $event, $exception) { // } }
To dispatch an event, you may pass an instance of the event to the event
helper. The helper will dispatch the event to all of its registered listeners. Since the event
helper is globally available, you may call it from anywhere in your application:
<?php namespace App\Http\Controllers; use App\Events\OrderShipped; use App\Http\Controllers\Controller; use App\Models\Order; class OrderController extends Controller { /** * Ship the given order. * * @param int $orderId * @return Response */ public function ship($orderId) { $order = Order::findOrFail($orderId); // Order shipment logic... event(new OrderShipped($order)); } }
Alternatively, if your event uses the Illuminate\Foundation\Events\Dispatchable
trait, you may call the static dispatch
method on the event. Any arguments passed to the dispatch
method will be passed to the event's constructor:
OrderShipped::dispatch($order);
When testing, it can be helpful to assert that certain events were dispatched without actually triggering their listeners. Laravel's built-in testing helpers makes it a cinch.
Event subscribers are classes that may subscribe to multiple events from within the class itself, allowing you to define several event handlers within a single class. Subscribers should define a subscribe
method, which will be passed an event dispatcher instance. You may call the listen
method on the given dispatcher to register event listeners:
<?php namespace App\Listeners; class UserEventSubscriber { /** * Handle user login events. */ public function handleUserLogin($event) {} /** * Handle user logout events. */ public function handleUserLogout($event) {} /** * Register the listeners for the subscriber. * * @param \Illuminate\Events\Dispatcher $events * @return void */ public function subscribe($events) { $events->listen( 'Illuminate\Auth\Events\Login', [UserEventSubscriber::class, 'handleUserLogin'] ); $events->listen( 'Illuminate\Auth\Events\Logout', [UserEventSubscriber::class, 'handleUserLogout'] ); } }
Alternatively, your subscriber's subscribe
method may return an array of event to handler mappings. In this case, the event listener mappings will be registered for you automatically:
use Illuminate\Auth\Events\Login; use Illuminate\Auth\Events\Logout; /** * Register the listeners for the subscriber. * * @return array */ public function subscribe() { return [ Login::class => [ [UserEventSubscriber::class, 'handleUserLogin'] ], Logout::class => [ [UserEventSubscriber::class, 'handleUserLogout'] ], ]; }
After writing the subscriber, you are ready to register it with the event dispatcher. You may register subscribers using the $subscribe
property on the EventServiceProvider
. For example, let's add the UserEventSubscriber
to the list:
<?php namespace App\Providers; use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider; class EventServiceProvider extends ServiceProvider { /** * The event listener mappings for the application. * * @var array */ protected $listen = [ // ]; /** * The subscriber classes to register. * * @var array */ protected $subscribe = [ 'App\Listeners\UserEventSubscriber', ]; }
© Taylor Otwell
Licensed under the MIT License.
Laravel is a trademark of Taylor Otwell.
https://laravel.com/docs/8.x/events