Django signals क्या हैं?

Question

Accepted Answer

**Signals** observer pattern का Django का कार्यान्वयन हैं — ये कुछ senders को विशिष्ट **events** होने पर (जैसे एक model का save या delete होना) receivers के एक समूह को सूचित करने देते हैं। ये **decoupled** code को सक्षम करते हैं: 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` save होता है, Django इस function को कॉल करता है — यहाँ, एक related `Profile` को auto-create करते हुए। `created` flag creation को updates से अलग करता है।

## एक विशिष्ट उपयोग मामला

```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 बनाने वाला code 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 code को **decouple** करने के लिए एक उपयोगी Django विशेषता हैं — एक application के विभिन्न हिस्सों को events (model saves/deletes, auth events) पर प्रतिक्रिया करने देते हुए बिना सीधी निर्भरताओं के, जो related objects को auto-create करना, cache invalidation, audit logging, और app boundaries के पार events पर प्रतिक्रिया जैसे cross-cutting concerns के लिए मूल्यवान है।

इन्हें समझना उन्हें उचित रूप से *उपयोग* करने और मौजूदा codebases में उन्हें पहचानने दोनों के लिए महत्वपूर्ण है (ये "यह क्यों हुआ?" भ्रम का एक सामान्य स्रोत हैं)।

हालाँकि, जो signals को एक विशेष रूप से महत्वपूर्ण विषय बनाता है वह है **कब उनका उपयोग करें इसके बारे में सूक्ष्म निर्णय**: जबकि वे सुंदर decoupling को सक्षम करते हैं, वे **implicit, "action-at-a-distance" व्यवहार** भी पैदा करते हैं जो code को follow और debug करना कठिन बना सकता है (एक object को save करना रहस्यमय रूप से कहीं और परिभाषित प्रभावों को ट्रिगर करता है)।

परिपक्व Django developers इस trade-off को समझते हैं — *वास्तविक* decoupling के लिए signals का उपयोग करते हुए (module/app boundaries के पार उन events पर प्रतिक्रिया करना जिन्हें आपको स्रोत से couple नहीं करना चाहिए) जबकि **explicit code** को प्राथमिकता देते हुए (logic को सीधे कॉल करना, `save()` को override करना, या service functions का उपयोग करना) जब logic स्पष्ट रूप से उसी flow में हो, क्योंकि explicit code अधिक पठनीय और traceable है।

signals कैसे काम करते हैं जानना (receivers जोड़ना, `created` flag, सामान्य signals), उनके वैध उपयोग मामले, और महत्वपूर्ण रूप से **कब उनका उपयोग न करें** (छिपे हुए, debug करने में कठिन व्यवहार से बचना) व्यावहारिक, अनुभवी समझ को दर्शाता है जो maintainable Django code लिखने वाले developers को उनसे अलग करता है जो signals का अति-उपयोग करते हैं और उलझे हुए, अपारदर्शी applications बनाते हैं।