Django signals म्हणजे काय?

Question

Accepted Answer

**Signals** हे Django मधील observer pattern चा अंमलबजावणी आहे — ते विशिष्ट **events** घडल्यावर (जसे model save किंवा delete होते) विशिष्ट senders एक संच receivers ला सूचित करू देतात. ते **decoupled** code सक्षम करतात: अ‍ॅप चा एक भाग दुसऱ्या भागातील events ला सरावस हिसेब न घेता प्रतिक्रिया देतो.

## सामान्य 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
```

## signal साठी receiver जोडणे

```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 कॉल करतो — येथे, संबंधित `Profile` ला auto-create करतात. `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-creating 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 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 हे code **decouple** करण्यासाठी Django चे उपयोगी feature आहे — application च्या विविध भागांना direct dependencies न घेता model saves/deletes, auth events यासारख्या events ला प्रतिक्रिया देऊ देते, जे auto-creating related objects, cache invalidation, audit logging, आणि app boundaries ओलांडून events ला प्रतिक्रिया देण्यासारख्या cross-cutting concerns साठी मूल्यवान आहे.

त्यांना समजून घेणे महत्वाचे आहे त्यांचा योग्यरित्या *वापर* करण्यासाठी आणि अस्तित्वात असलेल्या codebases मध्ये त्यांना ओळखण्यासाठी (ते "हे का घडले?" गोंधळाचे सामान्य स्रोत आहेत).

तथापि, signals ला विशेष महत्वाचा विषय बनवते हे **कधी त्यांचा वापर करायचा याचा सूक्ष्म निर्णय**: जरी ते elegant decoupling सक्षम करतात, ते **implicit, "action-at-a-distance" behavior** देखील तयार करतात जे code ला फॉलो आणि debug करणे कठीण करू शकते (object save करणे रहस्यमयपणे इतरत्र परिभाषित केलेले प्रभाव ट्रिगर करते).

पक्व Django developers हा trade-off समजतात — *genuine* decoupling साठी signals वापरतात (module/app boundaries ओलांडून events ला प्रतिक्रिया देतात ज्यांना तुम्हाला source ला couple करू नये) जरी **explicit code** **पसंत करतात** (logic सरावस कॉल करणे, `save()` override करणे, किंवा service functions वापरणे) जेव्हा logic स्पष्टपणे समान flow मध्ये असते, कारण explicit code अधिक वाचनीय आणि traceable आहे.

सignals कसे काम करतात हे जाणून घेणे (receivers जोडणे, `created` flag, सामान्य signals), त्यांचे वैध use cases, आणि महत्वाचे म्हणजे **कधी त्यांचा वापर न करायचा** (hidden, hard-to-debug behavior टाळणे) हे व्यावहारिक, अनुभवी समज प्रतिबिंबित करते जे developers ला वेगळे करते जे maintainable Django code लिहितात त्यांच्यापासून जे signals ला overuse करतात आणि tangled, opaque applications तयार करतात.