Hvordan fungerer events og listeners?

Question

Accepted Answer

Laravels **events og listeners** implementerer observer-mønstret — du **dispatcher en event** når noget bemærkelsesværdigt sker, og en eller flere **listeners** reagerer på det. Dette afkoblet kode: event-kilden behøver ikke at vide, hvem der svarer, hvilket muliggør en ren adskillelse af ansvar.

## Definering af en event og en 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 af event'en

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

Dispatching af event'en udløser alle dens registrerede listeners. Ordre-forsendelseskoden annoncerer blot hvad der skete — den ved ikke (og bekymrer sig ikke om), at emails, analysedata eller andre reaktioner forekommer.

## Flere listeners til en event (afkobling)

```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
```

Dette er den vigtigste fordel: du kan tilføje nye reaktioner (en listener) til en event uden at røre den kode, der dispatcher den — ren, udvidelig afkobling.

## Queued listeners (async)

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

Implementering af `ShouldQueue` gør, at en listener kører **asynkront** via køen — så langsomme reaktioner (afsendelse af email) forsinker ikke svaret.

## Hvorfor det betyder noget

Events og listeners er en brugbar Laravel-funktion til **afkobling** af kode — der giver forskellige dele af et program mulighed for at reagere på begivenheder uden tæt kobling, hvilket er værdifuldt for tværgående reaktioner og for at holde kode vedligeholdelig.

At forstå dem er nyttigt både for at bruge dem og for at genkende dem i kodebaser: mønstret lader dig dispatche en event, når noget betydningsfuldt sker (en ordre afsendes, en bruger registrerer sig) og få flere uafhængige listeners til at reagere (sende email, opdatere inventar, registrere analysedata), som hver håndterer en separat anligggende.

Den vigtigste fordel er **udvidelse gennem afkobling** — du kan tilføje nye reaktioner ved at registrere en listener uden at ændre den kode, der dispatcher event'en, hvilket holder anliggender adskilt og dispatcher-koden fokuseret.

Muligheden for at gøre listeners **queued** (`ShouldQueue`), så de kører asynkront, er også vigtig, hvilket tillader langsomme reaktioner (emails, eksterne API-kald) at finde sted i baggrunden uden at forsinke brugerens svar.

At vide hvordan events/listeners fungerer, deres afkoblingsfordel og queued listeners til asynkron behandling er værdifuld viden for at bygge velstrukturerede, udvidelige Laravel-applikationer. (Som med signaler i andre frameworks, er forbehold, at events skaber implicit, action-at-a-distance-adfærd, der kan være sværere at spore — så de bruges bedst til ægte tværgående afkobling i stedet for som standard for al post-action-logik, hvor eksplicit kode ofte er tydeligere.)