Hoe werken events en listeners?

Question

Accepted Answer

Laravel's **events en listeners** implementeren het observer pattern — je **dispatched een event** wanneer iets opmerkenswaardig gebeurt, en één of meer **listeners** reageren erop. Dit ontkoppelt code: de event-bron hoeft niet te weten wie reageert, wat een schone scheiding van zorgen mogelijk maakt.

## Defining an event and a listener

```php
// the event — a simple data carrier for "something happened"
class OrderShipped {
    public function __construct(public Order $order) {}
}

// a listener — reacts to the event
class SendShipmentNotification {
    public function handle(OrderShipped $event): void {
        Mail::to($event->order->customer)->send(new ShipmentMail($event->order));
    }
}
// generate with: php artisan make:event / make:listener
```

## Dispatching the event

```php
// when the order ships, DISPATCH the event — all listeners run
OrderShipped::dispatch($order);
// or: event(new OrderShipped($order));
```

De event dispatchen triggert alle geregistreerde listeners. De order-shipping code kondigt gewoon aan wat er is gebeurd — het weet niet (en het interesseert niet) dat emails, analytics, of andere reacties plaatsvinden.

## Multiple listeners for one event (decoupling)

```php
// one event can have MANY listeners — each a separate concern
OrderShipped → SendShipmentNotification    // email
            → UpdateInventory               // adjust stock
            → RecordAnalytics               // log the event
// add reactions without modifying the order-shipping code
```

Dit is het belangrijkste voordeel: je kunt nieuwe reacties (een listener) aan een event toevoegen zonder de code die het dispatched aan te raken — schone, uitbreidbare ontkoppeling.

## Queued listeners (async)

```php
class SendShipmentNotification implements ShouldQueue {   // run the listener in the BACKGROUND
    public function handle(OrderShipped $event): void { ... }
}
```

Door `ShouldQueue` te implementeren, wordt een listener **asynchron** via de queue uitgevoerd — zodat trage reacties (email verzenden) het response niet vertragen.

## Waarom het belangrijk is

Events en listeners zijn een nuttige Laravel-functie voor **ontkoppeling** van code — waardoor verschillende delen van een applicatie kunnen reageren op gebeurtenissen zonder nauwe koppeling, wat waardevol is voor cross-cutting reacties en het onderhouden van code.

Het begrijpen ervan is nuttig zowel voor het gebruiken als voor het herkennen ervan in codebases: het pattern stelt je in staat om een event te dispatchen wanneer iets significant gebeurt (een order wordt verzonden, een gebruiker registreert zich) en meerdere onafhankelijke listeners laten reageren (email verzenden, inventory bijwerken, analytics vastleggen), elk handelt een apart concern af.

Het belangrijkste voordeel is **uitbreidbaarheid door ontkoppeling** — je kunt nieuwe reacties toevoegen door een listener te registreren zonder de code die het event dispatched aan te passen, zodat concerns gescheiden blijven en de dispatching code gericht blijft.

De mogelijkheid om listeners **queued** (`ShouldQueue`) te maken zodat ze asynchron worden uitgevoerd is ook belangrijk, waardoor trage reacties (emails, externe API-calls) op de achtergrond plaatsvinden zonder het response van de gebruiker te vertragen.

Weten hoe events/listeners werken, hun ontkoppelingsbenefit, en queued listeners voor asynchrone verwerking is waardevolle kennis voor het bouwen van goed gestructureerde, uitbreidbare Laravel-applicaties. (Net als bij signalen in andere frameworks is de kanttekening dat events impliciet, action-at-a-distance gedrag creëren dat moeilijker te traceren kan zijn — dus ze worden het best gebruikt voor echte cross-cutting ontkoppeling in plaats van als standaard voor alle post-action logica, waar expliciete code vaak duidelijker is.)