Event dispatching in Laravel - Step-by-Step Execution

Concept Flow - Event dispatching

Trigger Event in Code

↓

Create Event Object

↓

Dispatch Event

↓

Listeners React

↓

Perform Actions

↓

Finish Event Cycle

This flow shows how Laravel creates and dispatches an event, then listeners respond to it.

Execution Sample

Laravel

event(new UserRegistered($user));

class UserRegistered {
  public $user;
  public function __construct($user) {
    $this->user = $user;
  }
}

This code creates a UserRegistered event with a user and dispatches it to listeners.

Execution Table

Step	Action	Event Object State	Listeners Called	Result
1	Create UserRegistered event with user data	UserRegistered { user: UserObject }	None yet	Event object ready
2	Dispatch event using event() helper	UserRegistered { user: UserObject }	Listener1, Listener2	Listeners start processing
3	Listener1 handles event	UserRegistered { user: UserObject }	Listener2 pending	Listener1 sends welcome email
4	Listener2 handles event	UserRegistered { user: UserObject }	None	Listener2 logs registration
5	Event dispatch cycle ends	UserRegistered { user: UserObject }	None	All listeners done

💡 All listeners have processed the dispatched event, ending the cycle.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 5
eventObject	null	UserRegistered { user: UserObject }	UserRegistered { user: UserObject }	UserRegistered { user: UserObject }
listenersCalled	[]	[]	[Listener1, Listener2]	[Listener1, Listener2]

Key Moments - 2 Insights

Why do listeners get called after dispatching the event?

Because dispatching triggers Laravel's event system to find and run all listeners registered for that event, as shown in steps 2 to 4 in the execution table.

What is inside the event object when dispatched?

The event object holds the data passed during creation, like the user in UserRegistered, visible in the eventObject variable in the tracker and step 1.

Visual Quiz - 3 Questions

Look at the execution table, what happens at step 3?

A Event object is created

B Listener1 sends a welcome email

C Listeners finish processing

D Event dispatch cycle ends

💡 Hint

Check the 'Result' column at step 3 in the execution table.

At which step are all listeners done processing the event?

A Step 5

B Step 4

C Step 2

D Step 1

💡 Hint

Look at the 'Listeners Called' and 'Result' columns in the execution table.

If the event object had no user data, what would change in the variable tracker?

A eventObject would be null after step 1

B listenersCalled would be empty after step 5

C eventObject would have no user property after step 1

D listenersCalled would include extra listeners

💡 Hint

Check the 'eventObject' row in variable_tracker after step 1.

Concept Snapshot

Laravel Event Dispatching:
- Create an event class with data.
- Dispatch event using event(new EventClass(data)).
- Laravel calls all registered listeners.
- Listeners perform actions like sending emails.
- Event cycle ends after all listeners run.

Full Transcript

In Laravel, event dispatching starts by creating an event object with data, like a user. Then, the event is dispatched using the event() helper. Laravel finds all listeners registered for that event and calls them one by one. Each listener performs its task, such as sending emails or logging. After all listeners finish, the event dispatch cycle ends. Variables like the event object and listeners called change during this process, as shown in the execution table and variable tracker.

Practice

1. What is the main purpose of event dispatching in Laravel?

easy

A. To create new routes for the application

B. To directly update the database records

C. To send messages about actions happening in the application

D. To handle user authentication automatically

Solution

1. Step 1: Understand event dispatching concept

   Event dispatching is used to send messages or signals when something happens in the app.

2. Step 2: Identify the correct purpose

   It is not about database updates, routing, or authentication but about notifying parts of the app.

3. Final Answer:

   To send messages about actions happening in the application -> Option C

4. Quick Check:

   Event dispatching = sending messages [OK]

Hint: Events notify parts of app about actions [OK]

Common Mistakes:

• Confusing events with database operations
• Thinking events create routes
• Assuming events handle authentication

2. Which of the following is the correct syntax to dispatch an event named UserRegistered with a user object $user?

easy

A. sendEvent('UserRegistered', $user);

B. dispatch(UserRegistered, $user);

C. UserRegistered::dispatch($user);

D. event(new UserRegistered($user));

Solution

1. Step 1: Recall Laravel event dispatch syntax

   Laravel uses the global event() helper with a new event instance.

2. Step 2: Match syntax with options

   Only event(new UserRegistered($user)); matches Laravel's pattern.

3. Final Answer:

   event(new UserRegistered($user)); -> Option D

4. Quick Check:

   Use event(new EventName($data)) [OK]

Hint: Use event(new EventName($data)) to dispatch [OK]

Common Mistakes:

• Using dispatch() without new keyword
• Calling event as a static method
• Using non-existent sendEvent function

3. Given the following code, what will be the output?

class OrderPlaced {
  public $orderId;
  public function __construct($orderId) {
    $this->orderId = $orderId;
  }
}

// Dispatch event
event(new OrderPlaced(123));

// Listener logs the order ID
Log::info('Order placed with ID: ' . 123);

medium

A. Logs: 'Order placed with ID: 123'

B. Logs: 'Order placed with ID: OrderPlaced'

C. No log output because event is not handled

D. Syntax error due to missing listener

Solution

1. Step 1: Understand event dispatch and listener

   The event OrderPlaced is dispatched with order ID 123, and the listener logs this ID.

2. Step 2: Check the log output

   The log line explicitly outputs 'Order placed with ID: 123'.

3. Final Answer:

   Logs: 'Order placed with ID: 123' -> Option A

4. Quick Check:

   Listener logs correct order ID [OK]

Hint: Listener logs event data as given [OK]

Common Mistakes:

• Assuming event dispatch alone logs output
• Confusing event class name with data
• Expecting error without listener registration

4. Identify the error in this event dispatching code:

event(UserRegistered($user));

medium

A. Missing the 'new' keyword before the event class

B. Incorrect event name, should be 'UserRegister'

C. Event dispatching requires a string, not an object

D. The variable $user is not passed correctly

Solution

1. Step 1: Check event dispatch syntax

   Laravel requires creating a new instance of the event class using new.

2. Step 2: Identify missing 'new' keyword

   The code calls UserRegistered($user) like a function, missing new.

3. Final Answer:

   Missing the 'new' keyword before the event class -> Option A

4. Quick Check:

   Use new EventClass($data) when dispatching [OK]

Hint: Always use new keyword before event class [OK]

Common Mistakes:

• Calling event class as function without new
• Wrong event class name
• Passing wrong data type

5. You want to dispatch an event ProfileUpdated only if the user's email has changed. Which code correctly implements this conditional event dispatch?

hard

A. ProfileUpdated::dispatch($user) when $user->email != old_email;

B. if ($user->isDirty('email')) { event(new ProfileUpdated($user)); }

C. event(new ProfileUpdated($user)) if $user->email_changed();

D. if ($user->email !== null) { dispatch(ProfileUpdated($user)); }

Solution

1. Step 1: Understand Laravel's model change detection

   The isDirty('email') method checks if the email attribute changed.

2. Step 2: Verify correct conditional event dispatch

   if ($user->isDirty('email')) { event(new ProfileUpdated($user)); } uses correct syntax and condition to dispatch event only if email changed.

3. Final Answer:

   if ($user->isDirty('email')) { event(new ProfileUpdated($user)); } -> Option B

4. Quick Check:

   Use isDirty() to check changes before event [OK]

Hint: Use isDirty('field') to check changes before event [OK]

Common Mistakes:

• Using incorrect syntax for condition
• Calling dispatch without new keyword
• Checking wrong condition for email change