Creating listeners in Laravel - Practice Exercises

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a Laravel event listener is triggered?

Consider a Laravel event listener that listens to a UserRegistered event. What is the expected behavior when the event is fired?

Laravel

class SendWelcomeEmail {
    public function handle(UserRegistered $event) {
        Mail::to($event->user->email)->send(new WelcomeEmail());
    }
}

// Event fired somewhere in the app
event(new UserRegistered($user));

A The listener logs the user out immediately.

B The listener updates the user's password automatically.

C The listener deletes the user from the database.

D The listener sends a welcome email to the registered user's email address.

💡 Hint

Think about what the listener's handle method is doing with the event data.

The listener's handle method uses the event's user data to send a welcome email. It does not perform any other actions like updating password, deleting user, or logging out.

📝 Syntax

intermediate

Which code correctly registers a listener in Laravel's EventServiceProvider?

You want to register a listener named SendWelcomeEmail for the UserRegistered event. Which code snippet correctly does this in the EventServiceProvider?

A

protected $listen = [
    'UserRegistered' => 'SendWelcomeEmail',
];

B

protected $listen = [
    UserRegistered::class => [
        SendWelcomeEmail::class,
    ],
];

C

protected $listen = [
    SendWelcomeEmail::class => UserRegistered::class,
];

D

protected $listeners = [
    UserRegistered => SendWelcomeEmail,
];

💡 Hint

Check the property name and the array structure for event to listeners mapping.

The correct property is $listen, mapping event class names to arrays of listener class names. Option B follows Laravel's standard syntax.

🔧 Debug

advanced

Why does this Laravel listener not respond to the event?

Given this listener code, why does it not respond when the event is fired? class LogUserLogin { public function handle(UserLoggedIn $event) { Log::info('User logged in: ' . $event->user->id); } } // EventServiceProvider protected $listen = [ UserLogin::class => [LogUserLogin::class], ];

A The listener class does not have a constructor, so it won't be called.

B The handle method should be named onUserLoggedIn to work properly.

C The event class name in the $listen array is incorrect; it should be UserLoggedIn::class, not UserLogin::class.

D The Log facade is not imported, causing a fatal error.

💡 Hint

Check the event class names used in the listener and the provider.

The event fired is UserLoggedIn but the provider listens for UserLogin, so the listener never triggers.

❓ state_output

advanced

What is the output when multiple listeners modify the same event data?

Consider an event OrderPlaced with a property $order->status initially 'pending'. Two listeners modify this status: Listener1: sets status to 'processing' Listener2: sets status to 'completed' If both listeners are registered and the event is fired, what will be the final status of the order?

A 'completed', because the last listener to run overwrites the status.

B 'processing', because the first listener sets the status and it cannot be changed.

C 'pending', because event data is immutable and cannot be changed by listeners.

D An error occurs because two listeners modify the same property.

💡 Hint

Think about how listeners run and modify shared event data.

Listeners run in order and can modify event data. The last listener's change will be the final state.

🧠 Conceptual

expert

Which statement about Laravel event listeners is true?

Select the correct statement about Laravel event listeners.

A Listeners can be queued to run asynchronously by implementing the ShouldQueue interface.

B Listeners must always be registered manually in the EventServiceProvider to work.

C Listeners cannot access the event data passed to them.

D Listeners automatically retry on failure without any configuration.

💡 Hint

Think about how Laravel handles long-running or delayed listener tasks.

Listeners that implement ShouldQueue are run asynchronously via Laravel's queue system. Manual registration is usually required but not always (e.g., auto-discovery). Listeners do receive event data. Automatic retries require explicit configuration.