Django signals کیا ہیں؟

Question

Accepted Answer

**Signals** Django کا observer pattern کا نفاذ ہیں — یہ کچھ senders کو ایک سیٹ receivers کو بتانے دیتے ہیں جب خاص **events** واقع ہوں (جیسے کہ ایک model محفوظ ہو یا حذف ہو)۔ یہ **decoupled** کوڈ کو فعال کرتے ہیں: app کا ایک حصہ دوسرے میں events پر عمل درآمد کرتا ہے براہ راست coupling کے بغیر۔

## عام 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 سے جوڑنا

```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 کو ایک مخصوص sender کے لیے signal سے جوڑتا ہے۔ جب ایک `User` محفوظ ہو، Django اس function کو کال کرتا ہے — یہاں، خودکار طور پر ایک متعلقہ `Profile` بناتے ہوئے۔ `created` flag creation کو updates سے الگ کرتا ہے۔

## ایک عام 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 بنانے والا کوڈ orders پر مرکوز رہتا ہے؛ 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
```

## اہم احتیاط: signals وضاحت کو نقصان پہنچا سکتے ہیں

```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 **decoupling** کوڈ کے لیے ایک مفید Django feature ہیں — application کے مختلف حصوں کو events (model saves/deletes، auth events) پر براہ راست dependencies کے بغیر عمل درآمد کرنے دیتے ہوئے، جو cross-cutting concerns جیسے خودکار طور پر متعلقہ objects بنانا، cache invalidation، audit logging، اور app boundaries میں events پر عمل درآمد کے لیے قیمتی ہے۔

انہیں سمجھنا دونوں کے لیے اہم ہے انہیں *مناسب طریقے سے استعمال کرنے* اور موجودہ code bases میں انہیں پہچاننے کے لیے (وہ "یہ کیوں ہوا؟" confusion کے ایک عام منبع ہیں)۔

تاہم، جو signals کو خاص طور پر اہم موضوع بناتا ہے وہ ہے انہیں استعمال کرنے کے بارے میں **nuanced judgment**: جبکہ وہ elegant decoupling کو فعال کرتے ہیں، وہ **implicit، "action-at-a-distance" behavior** بھی بناتے ہیں جو code کو follow اور debug کرنا مشکل بناتا ہے (ایک object محفوظ کرنا mysteriously effects کو محرک کرتا ہے جو کہیں اور defined ہیں)۔

پختہ Django developers اس trade-off کو سمجھتے ہیں — signals کو *genuine* decoupling کے لیے استعمال کرتے ہوئے (module/app boundaries میں events پر عمل درآمد کرتے ہوئے جو آپ کو source سے couple نہیں ہونے چاہیے) جبکہ **explicit code** کو ترجیح دیتے ہیں (logic کو براہ راست کال کرنا، `save()` کو override کرنا، یا service functions کو استعمال کرنا) جب logic واضح طور پر ایک ہی flow میں ہو، کیونکہ explicit code زیادہ readable اور traceable ہے۔

Signals کیسے کام کرتے ہیں یہ جاننا (receivers کو جوڑنا، `created` flag، عام signals)، ان کے legitimate use cases، اور اہم طور پر **انہیں کب NOT استعمال کریں** (hidden، hard-to-debug behavior سے بچنا) عملی، تجربے کار سمجھ کی عکاسی کرتا ہے جو ان developers کو الگ کرتا ہے جو maintainable Django code لکھتے ہیں ان سے جو signals کو overuse کرتے ہیں اور tangled، opaque applications بناتے ہیں۔