¿Cómo funcionan los eventos y listeners?

Question

Accepted Answer

Los **eventos y listeners** de Laravel implementan el patrón observador — **dispatch un evento** cuando algo notable ocurre, y uno o más **listeners** reaccionan a él. Esto desacopla el código: la fuente del evento no necesita saber quién responde, permitiendo una separación clara de responsabilidades.

## Por qué es importante

Los eventos y listeners son una característica útil de Laravel para **desacoplar** código — permitiendo que diferentes partes de una aplicación reaccionen a sucesos sin acoplamiento fuerte, lo cual es valioso para reacciones transversales y para mantener el código mantenible.

Comprenderlos es útil tanto para utilizarlos como para reconocerlos en bases de código: el patrón te permite disparar un evento cuando algo significativo ocurre (un pedido se envía, un usuario se registra) y tener múltiples listeners independientes que reaccionen (enviar email, actualizar inventario, registrar analítica), cada uno manejando una responsabilidad separada.

El beneficio clave es la **extensibilidad a través del desacoplamiento** — puedes añadir nuevas reacciones registrando un listener sin modificar el código que dispara el evento, manteniendo las responsabilidades separadas y el código que dispara el evento enfocado.

La capacidad de hacer listeners **encolables** (`ShouldQueue`) para que se ejecuten de forma asincrónica es también importante, permitiendo que reacciones lentas (emails, llamadas a API externas) ocurran en background sin retrasar la respuesta del usuario.

Conocer cómo funcionan los eventos/listeners, su beneficio de desacoplamiento, y los listeners encolables para procesamiento asincrónico es conocimiento valioso para construir aplicaciones Laravel bien estructuradas y extensibles. (Como con señales en otros frameworks, la advertencia es que los eventos crean comportamiento implícito de acción-a-distancia que puede ser más difícil de rastrear — por lo que es mejor usarlos para desacoplamiento transversal genuino en lugar de como predeterminado para toda la lógica post-acción, donde el código explícito es frecuentemente más claro.)

## Definiendo un evento y un 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
```

## Disparando el evento

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

Disparar el evento activa todos sus listeners registrados. El código de envío de pedidos simplemente anuncia qué sucedió — no sabe (ni le importa) que se envíen emails, se registre analítica, u otras reacciones ocurran.

## Múltiples listeners para un evento (desacoplamiento)

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

Este es el beneficio clave: puedes añadir nuevas reacciones (un listener) a un evento sin tocar el código que lo dispara — desacoplamiento limpio y extensible.

## Listeners encolables (asincrónico)

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

Implementar `ShouldQueue` hace que un listener se ejecute **asincronamente** a través de la cola — por lo que las reacciones lentas (enviar email) no retrasan la respuesta.