ما هي إشارات Django؟

Question

Accepted Answer

**الإشارات** هي تطبيق Django لنمط المراقب — فهي تسمح لمرسلين معينين بإخطار مجموعة من المستقبلات عند حدوث **أحداث** معينة (مثل حفظ أو حذف نموذج). تتيح **فصل المكونات**: يمكن لجزء من التطبيق أن يتفاعل مع الأحداث في جزء آخر دون اقتران مباشر.

## الإشارات المدمجة الشائعة

```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
```

## ربط جهاز استقبال بإشارة

```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` دالة بإشارة معينة لمرسل معين. عند حفظ `User`، يستدعي Django هذه الدالة — هنا، لإنشاء `Profile` مرتبط تلقائياً. يميز العلم `created` بين الإنشاء والتحديثات.

## حالة استخدام نموذجية

```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
```

يبقى كود إنشاء الطلبات منصباً على الطلبات؛ منطق البريد الإلكتروني يعيش بشكل منفصل ويتفاعل مع الحدث — مما يحافظ على فصل الاهتمامات.

## متى تكون الإشارات مفيدة

```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
```

## التحذير المهم: الإشارات يمكن أن تضر الوضوح

```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.
```

## لماذا يهم هذا

الإشارات هي ميزة Django مفيدة **لفصل المكونات** — تسمح لأجزاء مختلفة من التطبيق بالتفاعل مع الأحداث (حفظ/حذف النماذج، أحداث المصادقة) دون تبعيات مباشرة، وهو قيّم للمخاوف المتقاطعة مثل إنشاء الكائنات المرتبطة تلقائياً، وإبطال الذاكرة المؤقتة، وتسجيل الأنشطة، والتفاعل مع الأحداث عبر حدود التطبيق.

فهمها مهم لكل من **استخدام** الإشارات بشكل صحيح **وللتعرف عليها في قواعد الأكواد الموجودة (فهي مصدر شائع لالتباس "لماذا حدث هذا؟").

ومع ذلك، ما يجعل الإشارات موضوعاً مهماً بشكل خاص هو **الحكم الدقيق حول متى يتم استخدامها**: بينما تتيح فصل المكونات بأناقة، فإنها تنشئ أيضاً **سلوكاً ضمنياً "بعيد المدى"** الذي يمكن أن يجعل الكود أصعب في المتابعة والتصحيح (حفظ كائن يثير بشكل غامض تأثيرات محددة في مكان آخر).

يفهم مطورو Django الناضجون هذه المقابلة — باستخدام الإشارات لـ **فصل حقيقي** (الرد عبر حدود الوحدة/التطبيق للأحداث التي لا يجب أن تقترن بالمصدر) بينما يفضلون **الكود الصريح** (استدعاء المنطق مباشرة، تجاوز `save()`، أو استخدام دوال الخدمة) عندما ينتمي المنطق بوضوح في نفس التدفق، لأن الكود الصريح أكثر قابلية للقراءة والتتبع.

معرفة كيفية عمل الإشارات (ربط المستقبلات، علم `created`، الإشارات الشائعة)، وحالات الاستخدام الشرعية لها، والأهم **متى لا يتم استخدامها** (تجنب السلوك الخفي الصعب التصحيح) تعكس فهماً عملياً وخبرة يميز مطوري Django الذين يكتبون كوداً قابلاً للصيانة عن أولئك الذين يفرطون في استخدام الإشارات وينشئون تطبيقات معقدة وغامضة.