Django signals ਕੀ ਹਨ?

Question

Accepted Answer

**Signals** Django ਦਾ observer pattern ਦੀ implementation ਹੈ — ਇਹ ਕੁਝ senders ਨੂੰ receivers ਦੇ ਇੱਕ ਸੈੱਟ ਨੂੰ notify ਕਰਨ ਦਿੰਦੇ ਹਨ ਜਦੋਂ **events** ਆਉਂਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ ਇੱਕ model save ਜਾਂ delete ਹੋ ਰਿਹਾ ਹੋਵੇ)। ਉਹ **decoupled** code ਨੂੰ enable ਕਰਦੇ ਹਨ: app ਦਾ ਇੱਕ ਹਿੱਸਾ ਦੂਜੇ ਵਿੱਚ events ਦੀ ਪ্ਰਤੀਕ੍ਰਿਆ ਕਰਦਾ ਹੈ ਬਿਨਾਂ direct coupling ਦੇ।

## Common built-in signals

```text
pre_save / post_save      → before / after a model instance is saved
pre_delete / post_delete  → before / after a model instance is deleted
m2m_changed               → a ManyToMany relationship changed
request_started / finished→ request lifecycle
user_logged_in / out      → authentication events
```

## Receiver ਨੂੰ signal ਨਾਲ connect ਕਰਨਾ

```python
from django.db.models.signals import post_save
from django.dispatch import receiver

# automatically create a Profile whenever a User is created
@receiver(post_save, sender=User)
def create_profile(sender, instance, created, **kwargs):
    if created:                          # only on creation, not every save
        Profile.objects.create(user=instance)
```

`@receiver` decorator ਇੱਕ function ਨੂੰ ਇੱਕ specific sender ਲਈ signal ਨਾਲ connect ਕਰਦਾ ਹੈ। ਜਦੋਂ ਇੱਕ `User` save ਹੁੰਦਾ ਹੈ, Django ਇਸ function ਨੂੰ call ਕਰਦਾ ਹੈ — ਇੱਥੇ, auto-create ਕਰ ਰਿਹਾ ਹੈ ਇੱਕ ਸੰਬੰਧਿਤ `Profile`। `created` flag creation ਨੂੰ updates ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ।

## ਇੱਕ typical use case

```python
@receiver(post_save, sender=Order)
def send_order_confirmation(sender, instance, created, **kwargs):
    if created:
        send_email(instance.customer.email, "Order confirmed")
# the Order-creation code doesn't need to know about emails → decoupled
```

Order-creating code orders ਨੂੰ focus ਰੱਖਦਾ ਹੈ; email logic ਵੱਖ ਰਹਿੰਦੀ ਹੈ ਅਤੇ event ਦੀ ਪ্ਰਤੀਕ੍ਰਿਆ ਕਰਦੀ ਹੈ — concerns ਨੂੰ decoupled ਰੱਖਦਾ ਹੈ।

## ਜਦੋਂ signals ਉਪਯੋਗੀ ਹਨ

```text
✓ Reacting to model events from a DIFFERENT app/module (decoupling)
✓ Auto-creating related objects (Profile on User creation)
✓ Cache invalidation, search-index updates, audit logging on save/delete
✓ Cross-cutting reactions you don't want to embed in the core logic
```

## ਮਹੱਤਵਪੂਰਨ caveat: signals clarity ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾ ਸਕਦੇ ਹਨ

```python
# ⚠️ signals create IMPLICIT, "action at a distance" behavior:
# saving an Order triggers an email somewhere else — not obvious from the save call.
# This can make code HARDER to follow and debug.
```

```text
When to PREFER explicit code over signals:
  ✗ If the logic clearly belongs in the same flow → call it directly (more readable)
  ✗ Overusing signals → hidden, hard-to-trace behavior, debugging difficulty
  ✓ A common alternative: override the model's save() method, or use a service function,
    for logic tightly coupled to the operation
Use signals mainly for genuine DECOUPLING (reacting across app boundaries), not as
a default for all post-save logic.
```

## ਇਸ ਦਾ ਮਹੱਤਵ

Signals ਇੱਕ ਉਪਯੋਗੀ Django feature ਹੈ **decoupling** code ਲਈ — application ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਨੂੰ events ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਰਨ ਦਿੰਦਾ ਹੈ (model saves/deletes, auth events) ਬਿਨਾਂ direct dependencies ਦੇ, ਜੋ cross-cutting concerns ਲਈ ਮੁੱਲਵਾਨ ਹੈ ਜਿਵੇਂ ਕਿ auto-creating ਸੰਬੰਧਿਤ objects, cache invalidation, audit logging, ਅਤੇ app boundaries ਵਿੱਚ events ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਆ ਕਰਨਾ।

Inhaਰੀ ਹੋਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉਨ੍ਹਾਂ ਨੂੰ *ਸਠੀਕ ਢੰਗ ਨਾਲ* ਵਰਤਣ ਲਈ ਅਤੇ ਮੌਜੂਦਾ codebases ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਪਛਾਨਣ ਲਈ (ਉਹ "ਇਹ ਕਿਉਂ ਹੋਇਆ?" confusion ਦਾ ਇੱਕ ਆਮ ਸਰੋਤ ਹਨ)।
". ਜਾਂ, ਜੋ signals ਨੂੰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ topic ਬਣਾਉਂਦਾ ਹੈ ਉਹ ਹੈ **ਇਸ ਬਾਰੇ nuanced judgment ਕਦੋਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਣਾ ਹੈ**: ਜਦਕਿ ਉਹ elegant decoupling ਨੂੰ enable ਕਰਦੇ ਹਨ, ਉਹ **implicit, "action-at-a-distance"** behavior ਵੀ ਬਣਾਉਂਦੇ ਹਨ ਜੋ code ਨੂੰ follow ਅਤੇ debug ਕਰਨਾ ਮੁਸ਼ਕਲ ਬਣਾ ਸਕਦੇ ਹਨ (ਇੱਕ object save ਕਰਨਾ mysteriously effects ਨੂੰ trigger ਕਰਦਾ ਹੈ ਜੋ elsewhere ਵਿੱਚ defined ਹਨ)।

Practiced Django developers ਇਸ trade-off ਨੂੰ ਸਮਝਦੇ ਹਨ — signals ਨੂੰ *genuine* decoupling ਲਈ ਵਰਤਦੇ ਹਨ (module/app boundaries ਵਿੱਚ events ਨਾਲ react ਕਰਦੇ ਹਜ਼ ੋ ਤੁਸੀਂ source ਨਾਲ couple ਨਹੀਂ ਕਰਨਾ ਚਾਹਦੇ) ਜਦਕਿ **explicit code** ਨੂੰ prefer ਕਰਦੇ ਹਨ (direct ਲਾਜਿਕ ਨੂੰ call ਕਰਨਾ, `save()` ਨੂੰ override ਕਰਨਾ, ਜਾਂ service functions ਨੂੰ ਵਰਤਣਾ) ਜਦੋਂ logic ਸਪੱਸ਼ਟ ਢੰਗ ਨਾਲ ਉਸੇ flow ਵਿੱਚ ਸੰਬੰਧਿਤ ਹੈ, ਕਿਉਂਕਿ explicit code ਜ਼ਿਆਦਾ readable ਅਤੇ traceable ਹੈ।

Janning ਕਿ signals ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ (receivers ਨੂੰ connect ਕਰਨਾ, `created` flag, common signals), ਉਨ੍ਹਾਂ ਦੇ legitimate use cases, ਅਤੇ ਮਹੱਤਵਪੂਰਨ **ਜਦੋਂ ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਤਣਾ ਨਹੀਂ ਹੈ** (hidden, hard-to-debug behavior ਤੋਂ ਬਚਨਾ) ਪ੍ਰਯੋਗਿਕ, experienced understanding ਨੂੰ reflect ਕਰਦਾ ਹੈ ਜੋ developers ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ ਜੋ maintainable Django code ਲਿਖਦੇ ਹਨ ਉਨ੍ਹਾਂ ਤੋਂ ਜੋ signals ਨੂੰ overuse ਕਰਦੇ ਹਨ ਅਤੇ tangled, opaque applications ਬਣਾਉਂਦੇ ਹਨ।