Event subscribers in Laravel - Step-by-Step Execution

Concept Flow - Event subscribers

Define Subscriber Class

↓

Register Subscriber in EventServiceProvider

↓

Event Occurs

↓

Laravel Checks Subscriber Methods

↓

Call Matching Subscriber Method

↓

Handle Event Logic

↓

End

This flow shows how Laravel uses subscriber classes to listen and respond to events by calling matching methods.

Execution Sample

Laravel

class UserEventSubscriber {
  public function onUserLogin($event) {
    // handle login
  }
  public function subscribe($events) {
    $events->listen('UserLoggedIn', [self::class, 'onUserLogin']);
  }
}
// Register in EventServiceProvider
protected $subscribe = [UserEventSubscriber::class];

Defines a subscriber class with a method to handle a user login event and registers it to listen for that event.

Execution Table

Step	Action	Event Fired	Subscriber Method Called	Effect
1	Laravel boots and registers subscriber	None	None	Subscriber ready to listen
2	User logs in	UserLoggedIn	onUserLogin	Runs login handling code
3	Subscriber method executes	UserLoggedIn	onUserLogin	Processes event data
4	Event handling completes	UserLoggedIn	None	No more subscriber methods
5	No more events	None	None	End of event cycle

💡 No more events fired, subscriber methods completed

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
$event	null	UserLoggedIn instance	UserLoggedIn instance	null
Subscriber Registered	false	true	true	true

Key Moments - 2 Insights

Why does Laravel call the subscriber method when the event fires?

Because the subscriber class registers its methods to listen for specific events (see execution_table step 2), Laravel calls the matching method automatically.

What happens if the subscriber method is missing?

Laravel will not find a method to call for the event, so no subscriber action runs (no effect in execution_table step 2).

Visual Quiz - 3 Questions

Look at the execution table, which step shows the subscriber method running?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Check the 'Subscriber Method Called' column to see when 'onUserLogin' runs.

At which step does Laravel register the subscriber to listen for events?

A Step 1

B Step 2

C Step 3

D Step 5

💡 Hint

Look at the 'Action' column for subscriber registration.

If the event 'UserLoggedIn' never fires, what happens to the subscriber methods?

A They run anyway

B They never run

C They run once at registration

D Laravel throws an error

💡 Hint

Refer to the 'Event Fired' column in the execution table.

Concept Snapshot

Laravel Event Subscribers:
- Create a subscriber class with methods for events
- Define subscribe() to link events to methods
- Register subscriber in EventServiceProvider
- Laravel calls methods when events fire
- Helps organize event handling cleanly

Full Transcript

In Laravel, event subscribers are classes that listen for events and respond by running specific methods. First, you define a subscriber class with methods named for the events you want to handle. Inside the subscribe() method, you tell Laravel which events to listen for and which methods to call. Then, you register this subscriber class in the EventServiceProvider. When an event like UserLoggedIn fires, Laravel automatically calls the matching subscriber method, allowing you to handle the event logic. If the event never fires, the subscriber methods do not run. This system helps keep event handling organized and reusable.

Practice

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

easy

A. To replace middleware in routing

B. To group multiple event handlers in one class for better organization

C. To directly dispatch events to the database

D. To handle HTTP requests and responses

Solution

1. Step 1: Understand event subscribers role

   Event subscribers group multiple event handlers in one class to keep code organized.

2. Step 2: Compare with other options

   Options A, B, and D describe unrelated Laravel features like middleware, database dispatch, and HTTP handling.

3. Final Answer:

   To group multiple event handlers in one class for better organization -> Option B

4. Quick Check:

   Event subscribers organize handlers = C [OK]

Hint: Subscribers group handlers in one class for neat code [OK]

Common Mistakes:

• Confusing subscribers with middleware
• Thinking subscribers dispatch events
• Mixing subscribers with HTTP controllers

2. Which method must a Laravel event subscriber class implement to register its event handlers?

easy

A. boot()

B. handle()

C. listen()

D. subscribe()

Solution

1. Step 1: Recall subscriber method

   Laravel event subscribers use the subscribe() method to register event handlers.

2. Step 2: Eliminate other methods

   handle() is for event listeners, listen() is used in EventServiceProvider, boot() is for service providers.

3. Final Answer:

   subscribe() -> Option D

4. Quick Check:

   subscribe() registers handlers = A [OK]

Hint: Subscribers use subscribe() to register handlers [OK]

Common Mistakes:

• Using handle() instead of subscribe()
• Confusing listen() with subscribe()
• Thinking boot() is for subscribers

3. Given this subscriber class, what will happen when the UserRegistered event is fired?

class UserEventSubscriber {
    public function subscribe($events) {
        $events->listen('UserRegistered', [self::class, 'onUserRegistered']);
    }

    public function onUserRegistered($event) {
        echo 'User registered: ' . $event->user->name;
    }
}

medium

A. Nothing happens because subscribe is not called automatically

B. It will throw a syntax error

C. It will echo the registered user's name

D. It will echo 'User registered:' without the name

Solution

1. Step 1: Understand event firing and subscriber listening

   The subscriber listens for 'UserRegistered' and calls onUserRegistered which echoes the user's name.

2. Step 2: Confirm subscribe method usage

   Laravel calls subscribe() automatically when registered, so the handler runs and echoes the message with the name.

3. Final Answer:

   It will echo the registered user's name -> Option C

4. Quick Check:

   Event triggers echo with name = A [OK]

Hint: subscribe() auto-registers handlers; echo shows user name [OK]

Common Mistakes:

• Thinking subscribe() must be called manually
• Assuming syntax error due to self::class
• Ignoring the event object passed to handler

4. Identify the error in this subscriber class:

class OrderSubscriber {
    public function subscribe($events) {
        $events->listen('OrderPlaced', 'handleOrderPlaced');
    }

    public function handleOrderPlaced($event) {
        // process order
    }
}

medium

A. The listener callback should be an array with class and method

B. The handleOrderPlaced method must be static

C. The subscribe method must return a value

D. The event name should be lowercase

Solution

1. Step 1: Check listener callback format

   Laravel expects the listener callback as an array with class and method when used in subscribers.

2. Step 2: Analyze given code

   The code uses a string 'handleOrderPlaced' instead of [self::class, 'handleOrderPlaced'], causing a runtime error.

3. Final Answer:

   The listener callback should be an array with class and method -> Option A

4. Quick Check:

   Listener callback must be array = D [OK]

Hint: Use [ClassName::class, 'method'] for subscriber callbacks [OK]

Common Mistakes:

• Passing method name as string only
• Thinking subscribe must return a value
• Assuming method must be static

5. You want to create a subscriber that listens to OrderPlaced and OrderShipped events. Which is the correct way to register both handlers in the subscribe method?

hard

A. public function subscribe($events) {
$events->listen('OrderPlaced', [self::class, 'handleOrderPlaced']);
$events->listen('OrderShipped', [self::class, 'handleOrderShipped']);
}

B. public function subscribe($events) {
$events->listen(['OrderPlaced', 'OrderShipped'], [self::class, 'handleOrder']);
}

C. public function subscribe($events) {
$events->listen('OrderPlaced', 'handleOrderPlaced');
$events->listen('OrderShipped', 'handleOrderShipped');
}

D. public function subscribe($events) {
$events->listen('OrderPlaced', self::handleOrderPlaced);
$events->listen('OrderShipped', self::handleOrderShipped);
}

Solution

1. Step 1: Understand correct listener registration

   Each event must be registered separately with an array callback [Class, method].

2. Step 2: Evaluate options

   public function subscribe($events) { $events->listen('OrderPlaced', [self::class, 'handleOrderPlaced']); $events->listen('OrderShipped', [self::class, 'handleOrderShipped']); } correctly registers both events with proper callbacks. public function subscribe($events) { $events->listen(['OrderPlaced', 'OrderShipped'], [self::class, 'handleOrder']); } wrongly groups events in one call. public function subscribe($events) { $events->listen('OrderPlaced', 'handleOrderPlaced'); $events->listen('OrderShipped', 'handleOrderShipped'); } uses strings instead of array callbacks. public function subscribe($events) { $events->listen('OrderPlaced', self::handleOrderPlaced); $events->listen('OrderShipped', self::handleOrderShipped); } uses invalid syntax without quotes.

3. Final Answer:

   public function subscribe($events) { $events->listen('OrderPlaced', [self::class, 'handleOrderPlaced']); $events->listen('OrderShipped', [self::class, 'handleOrderShipped']); } -> Option A

4. Quick Check:

   Separate listen calls with array callbacks = B [OK]

Hint: Register each event separately with [Class::class, 'method'] [OK]

Common Mistakes:

• Grouping multiple events in one listen call
• Using string method names without array
• Using invalid syntax without quotes