ਇਵੈਂਟਾਂ ਅਤੇ ਲਿਸਨਰਾਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ?

Question

Accepted Answer

Laravel ਦੀ **events ਅਤੇ listeners** observer pattern ਨੂੰ ਲਾਗੂ ਕਰਦੀਆਂ ਹਨ — ਤੁਸੀਂ ਇੱਕ **event dispatch** ਕਰਦੇ ਹੋ ਜਦੋਂ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਘਟਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਜਾਂ ਵੱਧ **listeners** ਇਸ ਦੇ ਜਵਾਬ ਵਿੱਚ ਕਾਰਵਾਈ ਕਰਦੇ ਹਨ। ਇਹ ਕੋਡ ਨੂੰ ਡਿਕਪਲ ਕਰਦਾ ਹੈ: event source ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੋਣਾ ਪੇਂਦਾ ਕਿ ਕੌਣ ਜਵਾਬ ਦੇਵੇ, ਜੋ ਧਿਆਨ ਦੀ ਸਾਫ਼ ਵੰਡ ਨੂੰ ਮਾਨਤਾ ਦਿੰਦਾ ਹੈ।

## ਇੱਕ 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 ਕਰਨ ਨਾਲ ਇਸ ਦੇ ਸਾਰੇ ਰਜਿਸਟਰ ਕੀਤੇ listeners ਚਲਾਏ ਜਾਂਦੇ ਹਨ। Order-shipping ਕੋਡ ਸਿਰਫ਼ ਉਹ ਘਬਰਾਂਦਾ ਹੈ ਜੋ ਘਟਿਆ — ਇਸ ਨੂੰ ਪਤਾ ਨਹੀਂ (ਜਾਂ ਪਰਵਾਹ ਨਹੀਂ) ਕਿ ਈਮੇਲ, 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
```

ਇਹ ਮੁੱਖ ਫ਼ਾਇਦਾ ਹੈ: ਤੁਸੀਂ ਇੱਕ event ਵਿੱਚ ਨਵੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਆਵਾਂ (ਇੱਕ listener) ਜੋੜ ਸਕਦੇ ਹੋ — ਬਿਨਾਂ ਇਸ ਕੋਡ ਨੂੰ ਛੂਹਿਆ ਜੋ ਇਸ ਨੂੰ dispatch ਕਰਦਾ ਹੈ — ਸਾਫ਼, ਵਿਸਤਾਰ ਵਿੱਚ decoupling।

## Queued listeners (async)

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

`ShouldQueue` ਨੂੰ ਲਾਗੂ ਕਰਨ ਨਾਲ ਇੱਕ listener queue ਦੁਆਰਾ **asynchronously** ਚਲਦਾ ਹੈ — ਇਸ ਲਈ ਸਲੋ ਪ੍ਰਤੀਕ੍ਰਿਆਵਾਂ (ਈਮੇਲ ਭੇਜਣਾ) ਜਵਾਬ ਨੂੰ ਦੇਰ ਨਹੀਂ ਕਰਦੀਆਂ।

## ਇਹ ਕਿਉਂ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ

Events ਅਤੇ listeners ਕੋਡ ਨੂੰ **decouple** ਕਰਨ ਲਈ ਇੱਕ ਲਾਭਦਾਇਕ Laravel ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ — ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਨੂੰ ਘਟਨਾਵਾਂ ਦੇ ਪ੍ਰਤੀ ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਮਜ਼ਬੂਤ ਜੋੜ ਦੇ, ਜੋ cross-cutting ਪ੍ਰਤੀਕ੍ਰਿਆਵਾਂ ਅਤੇ ਕੋਡ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ ਕੀਮਤੀ ਹੈ।

ਇਨ੍ਹਾਂ ਨੂੰ ਸਮਝਣਾ ਉਪਯੋਗੀ ਹੈ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਣ ਅਤੇ codebase ਵਿੱਚ ਪਛਾਣਨ ਲਈ ਦੋਵਾਂ: pattern ਤੁਹਾਨੂੰ ਇੱਕ event dispatch ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਘਟਦਾ ਹੈ (ਇੱਕ order ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਇੱਕ user ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ) ਅਤੇ ਬਹੁਤ ਸਾਰੇ independent listeners ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਰੋ (ਈਮੇਲ ਭੇਜੋ, inventory ਨੂੰ ਅਪਡੇਟ ਕਰੋ, analytics ਨੂੰ ਰਿਕਾਰਡ ਕਰੋ), ਹਰ ਇੱਕ ਇੱਕ ਵੱਖਰੀ ਧਿਆਨ ਦਾ ਸੰਭਾਲ ਕਰਦਾ ਹੈ।

ਮੁੱਖ ਫ਼ਾਇਦਾ **decoupling ਦੁਆਰਾ extensibility** ਹੈ — ਤੁਸੀਂ ਇਸ ਕੋਡ ਨੂੰ ਸੋਧਿਆ ਬਿਨਾਂ ਇੱਕ listener ਨੂੰ ਰਜਿਸਟਰ ਕਰਕੇ ਨਵੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਆਵਾਂ ਜੋੜ ਸਕਦੇ ਹੋ ਜੋ event ਨੂੰ dispatch ਕਰਦਾ ਹੈ, ਧਿਆਨ ਨੂੰ ਵੱਖ ਕੀਤਾ ਰੱਖਦਾ ਹੈ ਅਤੇ dispatch ਕੋਡ ਨੂੰ ਫ਼ੋਕਸਡ ਕਰਦਾ ਹੈ।

Listeners ਨੂੰ **queued** ਕਰਨ ਦੀ ਯੋਗਤਾ (`ShouldQueue`) ਇਸ ਲਈ ਕਿ ਉਹ asynchronously ਚਲਣ ਲਈ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਸਲੋ ਪ੍ਰਤੀਕ੍ਰਿਆਵਾਂ (ਈਮੇਲ, external API ਕਾਲ) ਨੂੰ ਬੈਕਗ੍ਰਾਉਂਡ ਵਿੱਚ ਵਾਪਰਨ ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਯੂਜ਼ਰ ਦੇ ਜਵਾਬ ਨੂੰ ਦੇਰ ਕੀਤੇ।

Knowing ਕਿ events/listeners ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਦਾ decoupling ਫ਼ਾਇਦਾ, ਅਤੇ async ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ queued listeners well-structured, extensible Laravel ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਨਿਰਮਾਣ ਲਈ ਕੀਮਤੀ ਗਿਆਨ ਹੈ। (ਹੋਰ frameworks ਵਿੱਚ signals ਵਾਂਗ, caveat ਇਹ ਹੈ ਕਿ events implicit, action-at-a-distance behavior ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ trace ਕਰਨ ਲਈ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦੀਆਂ ਹਨ — ਇਸ ਲਈ ਉਹ genuine cross-cutting decoupling ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ ਭਾਵੇਂ ਸਾਰੀ post-action logic ਦੇ ਲਈ default ਵਜੋਂ ਨਹੀਂ, ਜਿੱਥੇ explicit code ਵਾਰ-ਵਾਰ ਸਪੱਸ਼ਟ ਹੁੰਦਾ ਹੈ।)