Events
- Introduction
- Generating Events and Listeners
- Registering Events and Listeners
- Defining Events
- Defining Listeners
- Queued Event Listeners
- Dispatching Events
- Event Subscribers
- Testing
Introduction
Laravel's events provide a simple observer pattern implementation, allowing you to subscribe and listen for various events that occur within 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 as 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 App\Events\OrderShipped
event which a listener can receive and use to dispatch a Slack notification.
Generating Events and Listeners
To quickly generate events and listeners, you may use the make:event
and make:listener
Artisan commands:
1php artisan make:event PodcastProcessed23php artisan make:listener SendPodcastNotification --event=PodcastProcessed
1php artisan make:event PodcastProcessed23php artisan make:listener SendPodcastNotification --event=PodcastProcessed
For convenience, you may also invoke the make:event
and make:listener
Artisan commands without additional arguments. When you do so, Laravel will automatically prompt you for the class name and, when creating a listener, the event it should listen to:
1php artisan make:event23php artisan make:listener
1php artisan make:event23php artisan make:listener
Registering Events and Listeners
Event Discovery
By default, Laravel will automatically find and register your event listeners by scanning your application's Listeners
directory. When Laravel finds any listener class method that begins with handle
or __invoke
, Laravel will register those methods as event listeners for the event that is type-hinted in the method's signature:
1use App\Events\PodcastProcessed;23class SendPodcastNotification4{5 /**6 * Handle the given event.7 */8 public function handle(PodcastProcessed $event): void9 {10 // ...11 }12}
1use App\Events\PodcastProcessed;23class SendPodcastNotification4{5 /**6 * Handle the given event.7 */8 public function handle(PodcastProcessed $event): void9 {10 // ...11 }12}
You may listen to multiple events using PHP's union types:
1/**2 * Handle the given event.3 */4public function handle(PodcastProcessed|PodcastPublished $event): void5{6 // ...7}
1/**2 * Handle the given event.3 */4public function handle(PodcastProcessed|PodcastPublished $event): void5{6 // ...7}
If you plan to store your listeners in a different directory or within multiple directories, you may instruct Laravel to scan those directories using the withEvents
method in your application's bootstrap/app.php
file:
1->withEvents(discover: [2 __DIR__.'/../app/Domain/Orders/Listeners',3])
1->withEvents(discover: [2 __DIR__.'/../app/Domain/Orders/Listeners',3])
The event:list
command may be used to list all of the listeners registered within your application:
1php artisan event:list
1php artisan event:list
Event Discovery in Production
To give your application a speed boost, you should cache a manifest of all of your application's listeners using the optimize
or event:cache
Artisan commands. Typically, this command should be run as part of your application's deployment process. 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 event cache.
Manually Registering Events
Using the Event
facade, you may manually register events and their corresponding listeners within the boot
method of your application's AppServiceProvider
:
1use App\Domain\Orders\Events\PodcastProcessed;2use App\Domain\Orders\Listeners\SendPodcastNotification;3use Illuminate\Support\Facades\Event;45/**6 * Bootstrap any application services.7 */8public function boot(): void9{10 Event::listen(11 PodcastProcessed::class,12 SendPodcastNotification::class,13 );14}
1use App\Domain\Orders\Events\PodcastProcessed;2use App\Domain\Orders\Listeners\SendPodcastNotification;3use Illuminate\Support\Facades\Event;45/**6 * Bootstrap any application services.7 */8public function boot(): void9{10 Event::listen(11 PodcastProcessed::class,12 SendPodcastNotification::class,13 );14}
The event:list
command may be used to list all of the listeners registered within your application:
1php artisan event:list
1php artisan event:list
Closure Listeners
Typically, listeners are defined as classes; however, you may also manually register closure-based event listeners in the boot
method of your application's AppServiceProvider
:
1use App\Events\PodcastProcessed;2use Illuminate\Support\Facades\Event;34/**5 * Bootstrap any application services.6 */7public function boot(): void8{9 Event::listen(function (PodcastProcessed $event) {10 // ...11 });12}
1use App\Events\PodcastProcessed;2use Illuminate\Support\Facades\Event;34/**5 * Bootstrap any application services.6 */7public function boot(): void8{9 Event::listen(function (PodcastProcessed $event) {10 // ...11 });12}
Queueable Anonymous Event Listeners
When registering closure based event listeners, you may wrap the listener closure within the Illuminate\Events\queueable
function to instruct Laravel to execute the listener using the queue:
1use App\Events\PodcastProcessed;2use function Illuminate\Events\queueable;3use Illuminate\Support\Facades\Event;45/**6 * Bootstrap any application services.7 */8public function boot(): void9{10 Event::listen(queueable(function (PodcastProcessed $event) {11 // ...12 }));13}
1use App\Events\PodcastProcessed;2use function Illuminate\Events\queueable;3use Illuminate\Support\Facades\Event;45/**6 * Bootstrap any application services.7 */8public function boot(): void9{10 Event::listen(queueable(function (PodcastProcessed $event) {11 // ...12 }));13}
Like queued jobs, you may use the onConnection
, onQueue
, and delay
methods to customize the execution of the queued listener:
1Event::listen(queueable(function (PodcastProcessed $event) {2 // ...3})->onConnection('redis')->onQueue('podcasts')->delay(now()->addSeconds(10)));
1Event::listen(queueable(function (PodcastProcessed $event) {2 // ...3})->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. This closure will receive the event instance and the Throwable
instance that caused the listener's failure:
1use App\Events\PodcastProcessed;2use function Illuminate\Events\queueable;3use Illuminate\Support\Facades\Event;4use Throwable;56Event::listen(queueable(function (PodcastProcessed $event) {7 // ...8})->catch(function (PodcastProcessed $event, Throwable $e) {9 // The queued listener failed...10}));
1use App\Events\PodcastProcessed;2use function Illuminate\Events\queueable;3use Illuminate\Support\Facades\Event;4use Throwable;56Event::listen(queueable(function (PodcastProcessed $event) {7 // ...8})->catch(function (PodcastProcessed $event, Throwable $e) {9 // The queued listener failed...10}));
Wildcard Event Listeners
You may also register listeners using the *
character 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:
1Event::listen('event.*', function (string $eventName, array $data) {2 // ...3});
1Event::listen('event.*', function (string $eventName, array $data) {2 // ...3});
Defining Events
An event class is essentially a data container which holds the information related to the event. For example, let's assume an App\Events\OrderShipped
event receives an Eloquent ORM object:
1<?php23namespace App\Events;45use App\Models\Order;6use Illuminate\Broadcasting\InteractsWithSockets;7use Illuminate\Foundation\Events\Dispatchable;8use Illuminate\Queue\SerializesModels;910class OrderShipped11{12 use Dispatchable, InteractsWithSockets, SerializesModels;1314 /**15 * Create a new event instance.16 */17 public function __construct(18 public Order $order,19 ) {}20}
1<?php23namespace App\Events;45use App\Models\Order;6use Illuminate\Broadcasting\InteractsWithSockets;7use Illuminate\Foundation\Events\Dispatchable;8use Illuminate\Queue\SerializesModels;910class OrderShipped11{12 use Dispatchable, InteractsWithSockets, SerializesModels;1314 /**15 * Create a new event instance.16 */17 public function __construct(18 public Order $order,19 ) {}20}
As you can see, this event class contains no logic. It is a container for the App\Models\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, such as when utilizing queued listeners.
Defining Listeners
Next, let's take a look at the listener for our example event. Event listeners receive event instances in their handle
method. The make:listener
Artisan command, when invoked with the --event
option, will automatically import the proper event class and type-hint the event in the handle
method. Within the handle
method, you may perform any actions necessary to respond to the event:
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;67class SendShipmentNotification8{9 /**10 * Create the event listener.11 */12 public function __construct() {}1314 /**15 * Handle the event.16 */17 public function handle(OrderShipped $event): void18 {19 // Access the order using $event->order...20 }21}
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;67class SendShipmentNotification8{9 /**10 * Create the event listener.11 */12 public function __construct() {}1314 /**15 * Handle the event.16 */17 public function handle(OrderShipped $event): void18 {19 // Access the order using $event->order...20 }21}
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.
Stopping The Propagation Of An Event
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.
Queued Event Listeners
Queueing listeners can be beneficial if your listener is going to perform a slow task such as sending an email or making an HTTP request. Before using queued listeners, make sure to configure your queue and start a queue worker 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 make:listener
Artisan commands already have this interface imported into the current namespace so you can use it immediately:
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;78class SendShipmentNotification implements ShouldQueue9{10 // ...11}
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;78class SendShipmentNotification implements ShouldQueue9{10 // ...11}
That's it! Now, when an event handled by this listener is dispatched, the listener will automatically be 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.
Customizing The Queue Connection, Name, & Delay
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:
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;78class SendShipmentNotification implements ShouldQueue9{10 /**11 * The name of the connection the job should be sent to.12 *13 * @var string|null14 */15 public $connection = 'sqs';1617 /**18 * The name of the queue the job should be sent to.19 *20 * @var string|null21 */22 public $queue = 'listeners';2324 /**25 * The time (seconds) before the job should be processed.26 *27 * @var int28 */29 public $delay = 60;30}
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;78class SendShipmentNotification implements ShouldQueue9{10 /**11 * The name of the connection the job should be sent to.12 *13 * @var string|null14 */15 public $connection = 'sqs';1617 /**18 * The name of the queue the job should be sent to.19 *20 * @var string|null21 */22 public $queue = 'listeners';2324 /**25 * The time (seconds) before the job should be processed.26 *27 * @var int28 */29 public $delay = 60;30}
If you would like to define the listener's queue connection, queue name, or delay at runtime, you may define viaConnection
, viaQueue
, or withDelay
methods on the listener:
1/**2 * Get the name of the listener's queue connection.3 */4public function viaConnection(): string5{6 return 'sqs';7}89/**10 * Get the name of the listener's queue.11 */12public function viaQueue(): string13{14 return 'listeners';15}1617/**18 * Get the number of seconds before the job should be processed.19 */20public function withDelay(OrderShipped $event): int21{22 return $event->highPriority ? 0 : 60;23}
1/**2 * Get the name of the listener's queue connection.3 */4public function viaConnection(): string5{6 return 'sqs';7}89/**10 * Get the name of the listener's queue.11 */12public function viaQueue(): string13{14 return 'listeners';15}1617/**18 * Get the number of seconds before the job should be processed.19 */20public function withDelay(OrderShipped $event): int21{22 return $event->highPriority ? 0 : 60;23}
Conditionally Queueing Listeners
Sometimes, you may need to determine whether a listener should be queued based on some data that are 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 queued:
1<?php23namespace App\Listeners;45use App\Events\OrderCreated;6use Illuminate\Contracts\Queue\ShouldQueue;78class RewardGiftCard implements ShouldQueue9{10 /**11 * Reward a gift card to the customer.12 */13 public function handle(OrderCreated $event): void14 {15 // ...16 }1718 /**19 * Determine whether the listener should be queued.20 */21 public function shouldQueue(OrderCreated $event): bool22 {23 return $event->order->subtotal >= 5000;24 }25}
1<?php23namespace App\Listeners;45use App\Events\OrderCreated;6use Illuminate\Contracts\Queue\ShouldQueue;78class RewardGiftCard implements ShouldQueue9{10 /**11 * Reward a gift card to the customer.12 */13 public function handle(OrderCreated $event): void14 {15 // ...16 }1718 /**19 * Determine whether the listener should be queued.20 */21 public function shouldQueue(OrderCreated $event): bool22 {23 return $event->order->subtotal >= 5000;24 }25}
Manually Interacting With the Queue
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:
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;7use Illuminate\Queue\InteractsWithQueue;89class SendShipmentNotification implements ShouldQueue10{11 use InteractsWithQueue;1213 /**14 * Handle the event.15 */16 public function handle(OrderShipped $event): void17 {18 if (true) {19 $this->release(30);20 }21 }22}
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;7use Illuminate\Queue\InteractsWithQueue;89class SendShipmentNotification implements ShouldQueue10{11 use InteractsWithQueue;1213 /**14 * Handle the event.15 */16 public function handle(OrderShipped $event): void17 {18 if (true) {19 $this->release(30);20 }21 }22}
Queued Event Listeners and Database Transactions
When queued listeners are dispatched within database transactions, they may be processed by the queue before the database transaction has committed. When this happens, any updates you have made to models or database records during the database transaction may not yet be reflected in the database. In addition, any models or database records created within the transaction may not exist in the database. If your listener depends on these models, unexpected errors can occur when the job that dispatches the queued listener is processed.
If your queue connection's after_commit
configuration option is set to false
, you may still indicate that a particular queued listener should be dispatched after all open database transactions have been committed by implementing the ShouldQueueAfterCommit
interface on the listener class:
1<?php23namespace App\Listeners;45use Illuminate\Contracts\Queue\ShouldQueueAfterCommit;6use Illuminate\Queue\InteractsWithQueue;78class SendShipmentNotification implements ShouldQueueAfterCommit9{10 use InteractsWithQueue;11}
1<?php23namespace App\Listeners;45use Illuminate\Contracts\Queue\ShouldQueueAfterCommit;6use Illuminate\Queue\InteractsWithQueue;78class SendShipmentNotification implements ShouldQueueAfterCommit9{10 use InteractsWithQueue;11}
To learn more about working around these issues, please review the documentation regarding queued jobs and database transactions.
Handling Failed Jobs
Sometimes your queued event listeners may fail. If the 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 Throwable
that caused the failure:
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;7use Illuminate\Queue\InteractsWithQueue;8use Throwable;910class SendShipmentNotification implements ShouldQueue11{12 use InteractsWithQueue;1314 /**15 * Handle the event.16 */17 public function handle(OrderShipped $event): void18 {19 // ...20 }2122 /**23 * Handle a job failure.24 */25 public function failed(OrderShipped $event, Throwable $exception): void26 {27 // ...28 }29}
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;7use Illuminate\Queue\InteractsWithQueue;8use Throwable;910class SendShipmentNotification implements ShouldQueue11{12 use InteractsWithQueue;1314 /**15 * Handle the event.16 */17 public function handle(OrderShipped $event): void18 {19 // ...20 }2122 /**23 * Handle a job failure.24 */25 public function failed(OrderShipped $event, Throwable $exception): void26 {27 // ...28 }29}
Specifying Queued Listener Maximum Attempts
If one of your queued listeners is encountering an error, you likely do not want it to keep retrying indefinitely. Therefore, Laravel provides various ways to specify how many times or for how long a listener may be attempted.
You may define a $tries
property on your listener class to specify how many times the listener may be attempted before it is considered to have failed:
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;7use Illuminate\Queue\InteractsWithQueue;89class SendShipmentNotification implements ShouldQueue10{11 use InteractsWithQueue;1213 /**14 * The number of times the queued listener may be attempted.15 *16 * @var int17 */18 public $tries = 5;19}
1<?php23namespace App\Listeners;45use App\Events\OrderShipped;6use Illuminate\Contracts\Queue\ShouldQueue;7use Illuminate\Queue\InteractsWithQueue;89class SendShipmentNotification implements ShouldQueue10{11 use InteractsWithQueue;1213 /**14 * The number of times the queued listener may be attempted.15 *16 * @var int17 */18 public $tries = 5;19}
As an alternative to defining how many times a listener may be attempted before it fails, you may define a time at which the listener should no longer be attempted. This allows a listener to be attempted any number of times within a given time frame. To define the time at which a listener should no longer be attempted, add a retryUntil
method to your listener class. This method should return a DateTime
instance:
1use DateTime;23/**4 * Determine the time at which the listener should timeout.5 */6public function retryUntil(): DateTime7{8 return now()->addMinutes(5);9}
1use DateTime;23/**4 * Determine the time at which the listener should timeout.5 */6public function retryUntil(): DateTime7{8 return now()->addMinutes(5);9}
Dispatching Events
To dispatch an event, you may call the static dispatch
method on the event. This method is made available on the event by the Illuminate\Foundation\Events\Dispatchable
trait. Any arguments passed to the dispatch
method will be passed to the event's constructor:
1<?php23namespace App\Http\Controllers;45use App\Events\OrderShipped;6use App\Http\Controllers\Controller;7use App\Models\Order;8use Illuminate\Http\RedirectResponse;9use Illuminate\Http\Request;1011class OrderShipmentController extends Controller12{13 /**14 * Ship the given order.15 */16 public function store(Request $request): RedirectResponse17 {18 $order = Order::findOrFail($request->order_id);1920 // Order shipment logic...2122 OrderShipped::dispatch($order);2324 return redirect('/orders');25 }26}
1<?php23namespace App\Http\Controllers;45use App\Events\OrderShipped;6use App\Http\Controllers\Controller;7use App\Models\Order;8use Illuminate\Http\RedirectResponse;9use Illuminate\Http\Request;1011class OrderShipmentController extends Controller12{13 /**14 * Ship the given order.15 */16 public function store(Request $request): RedirectResponse17 {18 $order = Order::findOrFail($request->order_id);1920 // Order shipment logic...2122 OrderShipped::dispatch($order);2324 return redirect('/orders');25 }26}
If you would like to conditionally dispatch an event, you may use the dispatchIf
and dispatchUnless
methods:
1OrderShipped::dispatchIf($condition, $order);23OrderShipped::dispatchUnless($condition, $order);
1OrderShipped::dispatchIf($condition, $order);23OrderShipped::dispatchUnless($condition, $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 make it a cinch.
Dispatching Events After Database Transactions
Sometimes, you may want to instruct Laravel to only dispatch an event after the active database transaction has committed. To do so, you may implement the ShouldDispatchAfterCommit
interface on the event class.
This interface instructs Laravel to not dispatch the event until the current database transaction is committed. If the transaction fails, the event will be discarded. If no database transaction is in progress when the event is dispatched, the event will be dispatched immediately:
1<?php23namespace App\Events;45use App\Models\Order;6use Illuminate\Broadcasting\InteractsWithSockets;7use Illuminate\Contracts\Events\ShouldDispatchAfterCommit;8use Illuminate\Foundation\Events\Dispatchable;9use Illuminate\Queue\SerializesModels;1011class OrderShipped implements ShouldDispatchAfterCommit12{13 use Dispatchable, InteractsWithSockets, SerializesModels;1415 /**16 * Create a new event instance.17 */18 public function __construct(19 public Order $order,20 ) {}21}
1<?php23namespace App\Events;45use App\Models\Order;6use Illuminate\Broadcasting\InteractsWithSockets;7use Illuminate\Contracts\Events\ShouldDispatchAfterCommit;8use Illuminate\Foundation\Events\Dispatchable;9use Illuminate\Queue\SerializesModels;1011class OrderShipped implements ShouldDispatchAfterCommit12{13 use Dispatchable, InteractsWithSockets, SerializesModels;1415 /**16 * Create a new event instance.17 */18 public function __construct(19 public Order $order,20 ) {}21}
Event Subscribers
Writing Event Subscribers
Event subscribers are classes that may subscribe to multiple events from within the subscriber 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:
1<?php23namespace App\Listeners;45use Illuminate\Auth\Events\Login;6use Illuminate\Auth\Events\Logout;7use Illuminate\Events\Dispatcher;89class UserEventSubscriber10{11 /**12 * Handle user login events.13 */14 public function handleUserLogin(Login $event): void {}1516 /**17 * Handle user logout events.18 */19 public function handleUserLogout(Logout $event): void {}2021 /**22 * Register the listeners for the subscriber.23 */24 public function subscribe(Dispatcher $events): void25 {26 $events->listen(27 Login::class,28 [UserEventSubscriber::class, 'handleUserLogin']29 );3031 $events->listen(32 Logout::class,33 [UserEventSubscriber::class, 'handleUserLogout']34 );35 }36}
1<?php23namespace App\Listeners;45use Illuminate\Auth\Events\Login;6use Illuminate\Auth\Events\Logout;7use Illuminate\Events\Dispatcher;89class UserEventSubscriber10{11 /**12 * Handle user login events.13 */14 public function handleUserLogin(Login $event): void {}1516 /**17 * Handle user logout events.18 */19 public function handleUserLogout(Logout $event): void {}2021 /**22 * Register the listeners for the subscriber.23 */24 public function subscribe(Dispatcher $events): void25 {26 $events->listen(27 Login::class,28 [UserEventSubscriber::class, 'handleUserLogin']29 );3031 $events->listen(32 Logout::class,33 [UserEventSubscriber::class, 'handleUserLogout']34 );35 }36}
If your event listener methods are defined within the subscriber itself, you may find it more convenient to return an array of events and method names from the subscriber's subscribe
method. Laravel will automatically determine the subscriber's class name when registering the event listeners:
1<?php23namespace App\Listeners;45use Illuminate\Auth\Events\Login;6use Illuminate\Auth\Events\Logout;7use Illuminate\Events\Dispatcher;89class UserEventSubscriber10{11 /**12 * Handle user login events.13 */14 public function handleUserLogin(Login $event): void {}1516 /**17 * Handle user logout events.18 */19 public function handleUserLogout(Logout $event): void {}2021 /**22 * Register the listeners for the subscriber.23 *24 * @return array<string, string>25 */26 public function subscribe(Dispatcher $events): array27 {28 return [29 Login::class => 'handleUserLogin',30 Logout::class => 'handleUserLogout',31 ];32 }33}
1<?php23namespace App\Listeners;45use Illuminate\Auth\Events\Login;6use Illuminate\Auth\Events\Logout;7use Illuminate\Events\Dispatcher;89class UserEventSubscriber10{11 /**12 * Handle user login events.13 */14 public function handleUserLogin(Login $event): void {}1516 /**17 * Handle user logout events.18 */19 public function handleUserLogout(Logout $event): void {}2021 /**22 * Register the listeners for the subscriber.23 *24 * @return array<string, string>25 */26 public function subscribe(Dispatcher $events): array27 {28 return [29 Login::class => 'handleUserLogin',30 Logout::class => 'handleUserLogout',31 ];32 }33}
Registering Event Subscribers
After writing the subscriber, Laravel will automatically register handler methods within the subscriber if they follow Laravel's event discovery conventions. Otherwise, you may manually register your subscriber using the subscribe
method of the Event
facade. Typically, this should be done within the boot
method of your application's AppServiceProvider
:
1<?php23namespace App\Providers;45use App\Listeners\UserEventSubscriber;6use Illuminate\Support\Facades\Event;7use Illuminate\Support\ServiceProvider;89class AppServiceProvider extends ServiceProvider10{11 /**12 * Bootstrap any application services.13 */14 public function boot(): void15 {16 Event::subscribe(UserEventSubscriber::class);17 }18}
1<?php23namespace App\Providers;45use App\Listeners\UserEventSubscriber;6use Illuminate\Support\Facades\Event;7use Illuminate\Support\ServiceProvider;89class AppServiceProvider extends ServiceProvider10{11 /**12 * Bootstrap any application services.13 */14 public function boot(): void15 {16 Event::subscribe(UserEventSubscriber::class);17 }18}
Testing
When testing code that dispatches events, you may wish to instruct Laravel to not actually execute the event's listeners, since the listener's code can be tested directly and separately of the code that dispatches the corresponding event. Of course, to test the listener itself, you may instantiate a listener instance and invoke the handle
method directly in your test.
Using the Event
facade's fake
method, you may prevent listeners from executing, execute the code under test, and then assert which events were dispatched by your application using the assertDispatched
, assertNotDispatched
, and assertNothingDispatched
methods:
1<?php23use App\Events\OrderFailedToShip;4use App\Events\OrderShipped;5use Illuminate\Support\Facades\Event;67test('orders can be shipped', function () {8 Event::fake();910 // Perform order shipping...1112 // Assert that an event was dispatched...13 Event::assertDispatched(OrderShipped::class);1415 // Assert an event was dispatched twice...16 Event::assertDispatched(OrderShipped::class, 2);1718 // Assert an event was not dispatched...19 Event::assertNotDispatched(OrderFailedToShip::class);2021 // Assert that no events were dispatched...22 Event::assertNothingDispatched();23});
1<?php23use App\Events\OrderFailedToShip;4use App\Events\OrderShipped;5use Illuminate\Support\Facades\Event;67test('orders can be shipped', function () {8 Event::fake();910 // Perform order shipping...1112 // Assert that an event was dispatched...13 Event::assertDispatched(OrderShipped::class);1415 // Assert an event was dispatched twice...16 Event::assertDispatched(OrderShipped::class, 2);1718 // Assert an event was not dispatched...19 Event::assertNotDispatched(OrderFailedToShip::class);2021 // Assert that no events were dispatched...22 Event::assertNothingDispatched();23});
1<?php23namespace Tests\Feature;45use App\Events\OrderFailedToShip;6use App\Events\OrderShipped;7use Illuminate\Support\Facades\Event;8use Tests\TestCase;910class ExampleTest extends TestCase11{12 /**13 * Test order shipping.14 */15 public function test_orders_can_be_shipped(): void16 {17 Event::fake();1819 // Perform order shipping...2021 // Assert that an event was dispatched...22 Event::assertDispatched(OrderShipped::class);2324 // Assert an event was dispatched twice...25 Event::assertDispatched(OrderShipped::class, 2);2627 // Assert an event was not dispatched...28 Event::assertNotDispatched(OrderFailedToShip::class);2930 // Assert that no events were dispatched...31 Event::assertNothingDispatched();32 }33}
1<?php23namespace Tests\Feature;45use App\Events\OrderFailedToShip;6use App\Events\OrderShipped;7use Illuminate\Support\Facades\Event;8use Tests\TestCase;910class ExampleTest extends TestCase11{12 /**13 * Test order shipping.14 */15 public function test_orders_can_be_shipped(): void16 {17 Event::fake();1819 // Perform order shipping...2021 // Assert that an event was dispatched...22 Event::assertDispatched(OrderShipped::class);2324 // Assert an event was dispatched twice...25 Event::assertDispatched(OrderShipped::class, 2);2627 // Assert an event was not dispatched...28 Event::assertNotDispatched(OrderFailedToShip::class);2930 // Assert that no events were dispatched...31 Event::assertNothingDispatched();32 }33}
You may pass a closure to the assertDispatched
or assertNotDispatched
methods in order to assert that an event was dispatched that passes a given "truth test". If at least one event was dispatched that passes the given truth test then the assertion will be successful:
1Event::assertDispatched(function (OrderShipped $event) use ($order) {2 return $event->order->id === $order->id;3});
1Event::assertDispatched(function (OrderShipped $event) use ($order) {2 return $event->order->id === $order->id;3});
If you would simply like to assert that an event listener is listening to a given event, you may use the assertListening
method:
1Event::assertListening(2 OrderShipped::class,3 SendShipmentNotification::class4);
1Event::assertListening(2 OrderShipped::class,3 SendShipmentNotification::class4);
After calling Event::fake()
, no event listeners will be executed. So, if your tests use model factories that rely on events, such as creating a UUID during a model's creating
event, you should call Event::fake()
after using your factories.
Faking a Subset of Events
If you only want to fake event listeners for a specific set of events, you may pass them to the fake
or fakeFor
method:
1test('orders can be processed', function () {2 Event::fake([3 OrderCreated::class,4 ]);56 $order = Order::factory()->create();78 Event::assertDispatched(OrderCreated::class);910 // Other events are dispatched as normal...11 $order->update([...]);12});
1test('orders can be processed', function () {2 Event::fake([3 OrderCreated::class,4 ]);56 $order = Order::factory()->create();78 Event::assertDispatched(OrderCreated::class);910 // Other events are dispatched as normal...11 $order->update([...]);12});
1/**2 * Test order process.3 */4public function test_orders_can_be_processed(): void5{6 Event::fake([7 OrderCreated::class,8 ]);910 $order = Order::factory()->create();1112 Event::assertDispatched(OrderCreated::class);1314 // Other events are dispatched as normal...15 $order->update([...]);16}
1/**2 * Test order process.3 */4public function test_orders_can_be_processed(): void5{6 Event::fake([7 OrderCreated::class,8 ]);910 $order = Order::factory()->create();1112 Event::assertDispatched(OrderCreated::class);1314 // Other events are dispatched as normal...15 $order->update([...]);16}
You may fake all events except for a set of specified events using the except
method:
1Event::fake()->except([2 OrderCreated::class,3]);
1Event::fake()->except([2 OrderCreated::class,3]);
Scoped Event Fakes
If you only want to fake event listeners for a portion of your test, you may use the fakeFor
method:
1<?php23use App\Events\OrderCreated;4use App\Models\Order;5use Illuminate\Support\Facades\Event;67test('orders can be processed', function () {8 $order = Event::fakeFor(function () {9 $order = Order::factory()->create();1011 Event::assertDispatched(OrderCreated::class);1213 return $order;14 });1516 // Events are dispatched as normal and observers will run ...17 $order->update([...]);18});
1<?php23use App\Events\OrderCreated;4use App\Models\Order;5use Illuminate\Support\Facades\Event;67test('orders can be processed', function () {8 $order = Event::fakeFor(function () {9 $order = Order::factory()->create();1011 Event::assertDispatched(OrderCreated::class);1213 return $order;14 });1516 // Events are dispatched as normal and observers will run ...17 $order->update([...]);18});
1<?php23namespace Tests\Feature;45use App\Events\OrderCreated;6use App\Models\Order;7use Illuminate\Support\Facades\Event;8use Tests\TestCase;910class ExampleTest extends TestCase11{12 /**13 * Test order process.14 */15 public function test_orders_can_be_processed(): void16 {17 $order = Event::fakeFor(function () {18 $order = Order::factory()->create();1920 Event::assertDispatched(OrderCreated::class);2122 return $order;23 });2425 // Events are dispatched as normal and observers will run ...26 $order->update([...]);27 }28}
1<?php23namespace Tests\Feature;45use App\Events\OrderCreated;6use App\Models\Order;7use Illuminate\Support\Facades\Event;8use Tests\TestCase;910class ExampleTest extends TestCase11{12 /**13 * Test order process.14 */15 public function test_orders_can_be_processed(): void16 {17 $order = Event::fakeFor(function () {18 $order = Order::factory()->create();1920 Event::assertDispatched(OrderCreated::class);2122 return $order;23 });2425 // Events are dispatched as normal and observers will run ...26 $order->update([...]);27 }28}