Τι είναι τα Django signals;

Question

Accepted Answer

**Signals** είναι η υλοποίηση του observer pattern από το Django — επιτρέπουν σε ορισμένους αποστολείς να ειδοποιήσουν ένα σύνολο δεκτών όταν συμβαίνουν συγκεκριμένα **events** (όπως η αποθήκευση ή διαγραφή ενός model). Ενεργοποιούν **decoupled** κώδικα: ένα μέρος της εφαρμογής αντιδρά σε events σε ένα άλλο μέρος χωρίς άμεση σύζευξη.

## Κοινά ενσωματωμένα 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 συνδέει μια συνάρτηση σε ένα signal για έναν συγκεκριμένο αποστολέα. Όταν ένα `User` αποθηκεύεται, το Django καλεί αυτή τη συνάρτηση — εδώ, δημιουργώντας αυτόματα ένα σχετικό `Profile`. Η σημαία `created` διακρίνει τη δημιουργία από τις ενημερώσεις.

## Ένα τυπικό 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
```

Ο κώδικας δημιουργίας παραγγελιών παραμένει εστιασμένος στις παραγγελίες· η λογική email ζει ξεχωριστά και αντιδρά στο event — διατηρώντας τις ανησυχίες 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 είναι μια χρήσιμη δυνατότητα του Django για **decoupling** κώδικα — επιτρέποντας σε διαφορετικά μέρη μιας εφαρμογής να αντιδρούν σε events (model saves/deletes, auth events) χωρίς άμεσες εξαρτήσεις, το οποίο είναι πολύτιμο για cross-cutting concerns όπως auto-creating related objects, cache invalidation, audit logging, και αντιδρώντας σε events σε όρια εφαρμογών.

Η κατανόηση τους είναι σημαντική τόσο για την *χρήση* τους κατάλληλα όσο και για την αναγνώρισή τους σε υπάρχοντες codebases (είναι μια συνηθισμένη πηγή σύγχυσης "γιατί συνέβη αυτό;").

Ωστόσο, αυτό που κάνει τα signals ένα ιδιαίτερα σημαντικό θέμα είναι η **λεπτή κρίση σχετικά με το πότε να τα χρησιμοποιήσετε**: ενώ ενεργοποιούν κομψό decoupling, δημιουργούν επίσης **implicit, "action-at-a-distance" behavior** που μπορεί να κάνει τον κώδικα πιο δύσκολο να ακολουθήσετε και να κάνετε debug (η αποθήκευση ενός αντικειμένου μυστηριωδώς ενεργοποιεί εφέ που ορίζονται αλλού).

Οι έμπειρες Django developers καταλαβαίνουν αυτή την ανταπόκριση — χρησιμοποιώντας signals για *genuine* decoupling (αντιδρώντας σε όρια module/app σε events που δεν θα πρέπει να συζευγνύσετε με την πηγή) ενώ προτιμώντας **explicit code** (κάλεσμα λογικής απευθείας, override `save()`, ή χρήση service functions) όταν η λογική σαφώς ανήκει στην ίδια ροή, επειδή το explicit code είναι πιο αναγνώσιμο και ιχνηλάσιμο.

Η γνώση του τρόπου λειτουργίας των signals (σύνδεση receivers, η σημαία `created`, κοινά signals), τα νόμιμα use cases τους, και κρίσιμα **πότε ΔΕΝ να τα χρησιμοποιήσετε** (αποφεύγοντας κρυμμένη, δύσκολη-to-debug behavior) αντικατοπτρίζει πρακτική, έμπειρη κατανόηση που διακρίνει developers που γράφουν maintainable Django κώδικα από εκείνους που κάνουν overuse signals και δημιουργούν ανακατεμένες, αδιάφανες εφαρμογές.