Jak działają zdarzenia i nasłuchiwacze?

Question

Accepted Answer

**Zdarzenia i nasłuchiwacze** w Laravelu implementują wzorzec Observer — **wysyłasz zdarzenie** gdy coś ważnego się dzieje, a jeden lub więcej **nasłuchiwaczy** reaguje na to. To rozdziela kod: źródło zdarzenia nie musi wiedzieć, kto odpowiada, umożliwiając czysty podział odpowiedzialności.

## Definiowanie zdarzenia i nasłuchiwacza

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

## Wysyłanie zdarzenia

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

Wysłanie zdarzenia uruchamia wszystkich jego zarejestrowanych nasłuchiwaczy. Kod wysyłki zamówienia po prostu ogłasza, co się stało — nie wie (i nie obchodzi go), że następują e-maile, analityka lub inne reakcje.

## Wielu nasłuchiwaczy dla jednego zdarzenia (rozdzielenie)

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

To jest kluczowa korzyść: możesz dodać nowe reakcje (nasłuchiwacza) do zdarzenia bez dotykania kodu, który je wysyła — czyste, rozszerzalne rozdzielenie.

## Nasłuchiwacze w kolejce (asynchronicznie)

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

Implementacja `ShouldQueue` powoduje, że nasłuchiwacz działa **asynchronicznie** za pośrednictwem kolejki — wolne reakcje (wysyłanie e-maila) nie opóźniają odpowiedzi.

## Dlaczego to ważne

Zdarzenia i nasłuchiwacze to przydatna funkcja Laravela do **rozdzielenia kodu** — pozwalając różnym częściom aplikacji reagować na zdarzenia bez ścisłego powiązania, co jest wartościowe dla reaction cross-cutting i utrzymywania kodu w dobrym stanie.

Zrozumienie ich jest pomocne zarówno do ich używania, jak i rozpoznawania ich w bazach kodów: wzorzec pozwala na wysłanie zdarzenia gdy coś znaczącego się dzieje (zamówienie zostaje wysłane, użytkownik się rejestruje) i mieć wielu niezależnych nasłuchiwaczy reagujących (wysłanie e-maila, aktualizacja magazynu, rejestrowanie analityki), każdy obsługujący oddzielną odpowiedzialność.

Główną korzyścią jest **rozszerzalność poprzez rozdzielenie** — możesz dodać nowe reakcje rejestrując nasłuchiwacza bez modyfikacji kodu, który wysyła zdarzenie, utrzymując separację odpowiedzialności i skupienie kodu wysyłającego.

Możliwość aby nasłuchiwacze były **w kolejce** (`ShouldQueue`), aby działały asynchronicznie, jest również ważna, pozwalając wolnym reakcjom (e-maile, wywołania zewnętrznych API) zachodzić w tle bez opóźniania odpowiedzi użytkownika.

Wiedzieć jak działają zdarzenia/nasłuchiwacze, ich korzyść rozdzielenia i nasłuchiwacze w kolejce do asynchronicznego przetwarzania to wartościowa wiedza do budowania dobrze ustrukturyzowanych, rozszerzalnych aplikacji Laravel. (Podobnie jak sygnały w innych frameworkach, zastrzeżenie polega na tym, że zdarzenia tworzą niejawne, działające z dystansu zachowanie, które może być trudniejsze do śledzenia — dlatego najlepiej są używane do prawdziwego cross-cutting rozdzielenia, a nie jako domyślne dla całej logiki po akcji, gdzie jawny kod jest często jaśniejszy.)