Events और listeners कैसे काम करते हैं?

Question

Accepted Answer

Laravel के **events और listeners** observer pattern को implement करते हैं — जब कुछ उल्लेखनीय होता है तो आप एक **event dispatch करते हैं**, और एक या अधिक **listeners** इस पर प्रतिक्रिया देते हैं। यह code को decouple करता है: event source को यह जानने की आवश्यकता नहीं होती कि कौन प्रतिक्रिया देता है, जिससे concerns का clean separation सक्षम होता है।

## एक event और एक 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
```

## event dispatch करना

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

Event को dispatch करना इसके सभी registered listeners को trigger करता है। order-shipping code बस यह घोषित करता है कि क्या हुआ — यह नहीं जानता (या परवाह नहीं करता) कि emails, analytics, या अन्य प्रतिक्रियाएँ होती हैं।

## एक event के लिए कई listeners (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
```

यह मुख्य लाभ है: आप उस code को छुए बिना एक event में नई प्रतिक्रियाएँ (एक listener) जोड़ सकते हैं जो इसे dispatch करता है — clean, extensible decoupling।

## Queued listeners (async)

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

`ShouldQueue` को implement करना एक listener को queue के माध्यम से **asynchronously** चलाता है — ताकि धीमी प्रतिक्रियाएँ (email भेजना) response में देरी न करें।

## यह क्यों महत्वपूर्ण है

Events और listeners code को **decouple** करने के लिए एक उपयोगी Laravel feature हैं — किसी application के विभिन्न हिस्सों को tight coupling के बिना घटनाओं पर प्रतिक्रिया देने देते हुए, जो cross-cutting प्रतिक्रियाओं और code को maintainable रखने के लिए मूल्यवान है।

उन्हें समझना उन्हें उपयोग करने और codebases में पहचानने दोनों के लिए सहायक है: pattern आपको कुछ महत्वपूर्ण होने पर (एक order ship होता है, एक user register होता है) एक event dispatch करने देता है और कई स्वतंत्र listeners को प्रतिक्रिया देने देता है (email भेजना, inventory update करना, analytics record करना), प्रत्येक एक अलग concern handle करते हुए।

मुख्य लाभ **decoupling के माध्यम से extensibility** है — आप उस code को संशोधित किए बिना एक listener register करके नई प्रतिक्रियाएँ जोड़ सकते हैं जो event dispatch करता है, concerns को अलग और dispatching code को केंद्रित रखते हुए।

listeners को **queued** (`ShouldQueue`) बनाने की क्षमता ताकि वे asynchronously चलें, भी महत्वपूर्ण है, जो धीमी प्रतिक्रियाओं (emails, external API calls) को user के response में देरी किए बिना background में होने देता है।

Events/listeners कैसे काम करते हैं, उनका decoupling लाभ, और async processing के लिए queued listeners जानना अच्छी तरह से संरचित, extensible Laravel applications बनाने के लिए मूल्यवान ज्ञान है। (जैसा कि अन्य frameworks में signals के साथ होता है, सावधानी यह है कि events implicit, action-at-a-distance behavior बनाते हैं जिसे trace करना कठिन हो सकता है — इसलिए वे सभी post-action logic के लिए एक default के बजाय वास्तविक cross-cutting decoupling के लिए सबसे अच्छे उपयोग किए जाते हैं, जहाँ explicit code अक्सर अधिक स्पष्ट होता है।)