Why event-driven architecture decouples code in Laravel - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to dispatch an event in Laravel.

Laravel

<?php

use App\Events\UserRegistered;

function registerUser($user) {
    // Dispatch the event
    event(new [1]($user));
}

Drag options to blanks, or click blank then click option'

AUserRegistered

BUserListener

CUserController

DUserModel

Attempts:

3 left

💡 Hint

Common Mistakes

Using a listener or controller class instead of the event class.

Not using the 'new' keyword before the event class.

In Laravel, events are dispatched by creating a new event instance and passing it to the event() helper. Here, UserRegistered is the event class.

2fill in blank

medium

Complete the code to listen for the UserRegistered event in Laravel.

Laravel

<?php

namespace App\Listeners;

use App\Events\UserRegistered;

class SendWelcomeEmail
{
    public function handle([1] $event)
    {
        // Send email logic here
    }
}

Drag options to blanks, or click blank then click option'

AUserRegistered

BUserListener

CUserController

DUserModel

Attempts:

3 left

💡 Hint

Common Mistakes

Using the listener class name as the parameter type.

Omitting the type hint.

The listener's handle method receives the event object as a parameter. The type hint must match the event class, here UserRegistered.

3fill in blank

hard

Fix the error in the event listener registration in Laravel's EventServiceProvider.

Laravel

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

Drag options to blanks, or click blank then click option'

AUserListener

BUserRegistered

CUserController

DUserModel

Attempts:

3 left

💡 Hint

Common Mistakes

Using the listener class as the key instead of the event class.

Using a controller or model class instead of the event class.

The $listen array maps event classes to their listeners. The key must be the event class, here UserRegistered::class.

4fill in blank

hard

Fill both blanks to create a listener that handles the event and logs a message.

Laravel

<?php

namespace App\Listeners;

use App\Events\UserRegistered;
use Illuminate\Support\Facades\Log;

class LogUserRegistration
{
    public function handle([1] $event)
    {
        Log::[2]('User registered: ' . $event->user->email);
    }
}

Drag options to blanks, or click blank then click option'

AUserRegistered

Binfo

Cerror

DUserListener

Attempts:

3 left

💡 Hint

Common Mistakes

Using the listener class as the parameter type.

Using Log::error instead of Log::info for normal logs.

The handle method receives the event object typed as UserRegistered. The Log::info method logs an informational message.

5fill in blank

hard

Fill all three blanks to create an event-driven flow that dispatches an event, listens, and handles it.

Laravel

<?php

// Dispatch event
function registerUser($user) {
    event(new [1]($user));
}

// Listener handle method
class SendNotification
{
    public function handle([2] $event)
    {
        // Notify user
        notify($event->user);
    }
}

// EventServiceProvider mapping
protected $listen = [
    [3]::class => [
        SendNotification::class,
    ],
];

Drag options to blanks, or click blank then click option'

AUserRegistered

DUserListener

Attempts:

3 left

💡 Hint

Common Mistakes

Using different class names in dispatch, handle, and mapping.

Using listener class name instead of event class.

All blanks require the event class UserRegistered to correctly connect dispatching, listening, and mapping in Laravel's event-driven architecture.

Practice

1. What is the main reason event-driven architecture helps decouple code in Laravel?

easy

A. It separates concerns by using events and listeners to handle actions independently.

B. It forces all code to run in a single file for simplicity.

C. It requires all logic to be written inside controllers only.

D. It combines all functions into one big method to reduce files.

Solution

1. Step 1: Understand event-driven architecture basics

   Event-driven architecture uses events to signal that something happened and listeners to react to those events separately.

2. Step 2: Recognize how this separation affects code

   By separating event triggers and listeners, code parts don't depend directly on each other, making maintenance easier.

3. Final Answer:

   It separates concerns by using events and listeners to handle actions independently. -> Option A

4. Quick Check:

   Event-driven separation = Decoupled code [OK]

Hint: Events and listeners keep code parts independent [OK]

Common Mistakes:

• Thinking all code must be in one file
• Believing event-driven means combining logic tightly
• Confusing events with direct method calls

2. Which of the following is the correct way to define an event class in Laravel?

easy

A. class UserRegistered extends Event { public function __construct() {} }

B. function UserRegistered() { return new Event(); }

C. event UserRegistered { public $user; }

D. class UserRegistered implements Listener { public function handle() {} }

Solution

1. Step 1: Recall Laravel event class syntax

   Laravel events are defined as classes usually extending the base Event class or just plain classes with constructor.

2. Step 2: Check each option's syntax

   A function definition is invalid for an event. 'event UserRegistered {}' is not valid PHP syntax. A class implementing Listener is for listeners, not events. Only the class extending Event with constructor is correct.

3. Final Answer:

   class UserRegistered extends Event { public function __construct() {} } -> Option A

4. Quick Check:

   Event class = class with constructor [OK]

Hint: Events are classes, not functions or interfaces [OK]

Common Mistakes:

• Defining events as functions
• Confusing event and listener roles
• Using invalid syntax for classes

3. Given this Laravel event and listener setup:

event(new UserRegistered($user));

What happens when the event is fired?

medium

A. The event deletes the user from the database.

B. The event immediately returns a value to the caller.

C. Nothing happens unless you call the listener manually.

D. All listeners registered for UserRegistered will run their handle methods.

Solution

1. Step 1: Understand Laravel event firing

   When you call event(new UserRegistered($user)), Laravel triggers all listeners registered for that event.

2. Step 2: Identify listener behavior

   Listeners react by running their handle methods automatically; no manual call needed.

3. Final Answer:

   All listeners registered for UserRegistered will run their handle methods. -> Option D

4. Quick Check:

   Firing event = triggers listeners [OK]

Hint: Firing event runs all its listeners automatically [OK]

Common Mistakes:

• Expecting event to return a value
• Thinking listeners run only if called manually
• Assuming event deletes data

4. You wrote this listener in Laravel:

class SendWelcomeEmail implements ShouldQueue { public function handle(UserRegistered $event) { Mail::send(...); }}

But the email is never sent. What is the likely problem?

medium

A. The listener class is missing the ShouldQueue interface.

B. The event is not being fired anywhere in the code.

C. The listener is queued but the queue worker is not running.

D. The handle method has the wrong parameter type.

Solution

1. Step 1: Analyze listener with ShouldQueue

   Implementing ShouldQueue means the listener runs asynchronously via queue workers.

2. Step 2: Check common queue issues

   If the queue worker is not running, queued listeners never execute, so email won't send.

3. Final Answer:

   The listener is queued but the queue worker is not running. -> Option C

4. Quick Check:

   Queued listener needs running queue worker [OK]

Hint: Queued listeners need active queue workers [OK]

Common Mistakes:

• Forgetting to run queue worker
• Assuming event not fired without checking
• Misunderstanding ShouldQueue role

5. How does using event-driven architecture in Laravel improve app maintainability when adding new features?

hard

A. You must rewrite all event classes to add new features.

B. You can add new listeners for events without changing existing event triggers.

C. All logic must be combined into one listener for simplicity.

D. Events automatically update database schemas for new features.

Solution

1. Step 1: Understand event-driven extensibility

   Events act as signals; you can add new listeners to respond to these signals without changing the event itself.

2. Step 2: Recognize how this aids maintainability

   This means new features can be added by creating new listeners, keeping existing code untouched and stable.

3. Final Answer:

   You can add new listeners for events without changing existing event triggers. -> Option B

4. Quick Check:

   New listeners = easier feature addition [OK]

Hint: Add listeners, not change events, to extend features [OK]

Common Mistakes:

• Thinking events must be rewritten for new features
• Combining all logic in one listener
• Expecting events to modify database automatically