Ce sunt semnalele Django?

Question

Accepted Answer

**Semnalele** sunt implementarea modelului observer de către Django — ele permit anumitor expeditori să notifice un set de receptori atunci când se produc anumite **evenimente** (cum ar fi salvarea sau ștergerea unui model). Ele permit cod **decuplat**: o parte a aplicației reacționează la evenimente din alta fără cuplare directă.

## Semnale built-in comune

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

## Conectarea unui receptor la un semnal

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

Decoratorul `@receiver` conectează o funcție la un semnal pentru un anumit expeditor. Când un `User` este salvat, Django apelează această funcție — aici, creează automat un `Profile` asociat. Indicatorul `created` diferențiază crearea de actualizări.

## Un caz de utilizare tipic

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

Codul care creează comenzile rămâne focalizat pe comenzi; logica de email trăiește separat și reacționează la eveniment — menținând preocupările decuplate.

## Când sunt utile semnalele

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

## Avertismentul important: semnalele pot afecta claritatea

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

## De ce conteaza

Semnalele sunt o caracteristică utilă Django pentru **decuplarea** codului — permițând diferitelor părți ale unei aplicații să reacționeze la evenimente (salvări/ștergeri de modele, evenimente de autentificare) fără dependențe directe, ceea ce este valoros pentru preocupări transversale cum ar fi crearea automată a obiectelor asociate, invalidarea cache-ului, jurnalizarea de audit și reacția la evenimente pe limitele aplicațiilor.

Înțelegerea lor este importantă atât pentru *utilizarea* lor adecvată, cât și pentru recunoașterea lor în bazele de cod existente (sunt o sursă comună de confuzie "de ce s-a întâmplat asta?").

Cu toate acestea, ceea ce face semnalele un subiect deosebit de important este **judecata nuanțată cu privire la când să le folosești**: deși permit decuplare elegantă, creează și **comportament implicit, "acțiune-la-distanță"** care poate face codul mai greu de urmărit și de depanat (salvarea unui obiect declanșează misterios efecte definite în altă parte).

DezvoltatoriExperi Django înțeleg acest compromis — folosind semnale pentru *decuplarea autentic* (reacționând pe limitele modulului/aplicației la evenimente la care nu ar trebui să cupleze sursa) în timp ce preferă **codul explicit** (apelând logica direct, suprascriind `save()`, sau folosind funcții de serviciu) atunci când logica aparține clar aceluiași flux, deoarece codul explicit este mai lizibil și mai ușor de urmărit.

Cunoașterea modului în care funcționează semnalele (conectarea receptorilor, indicatorul `created`, semnale comune), cazurile lor de utilizare legitime, și în mod crucial **când NU să le folosești** (evitând comportament ascuns, greu de depanat) reflectă o înțelegere practică și experimentată care diferențiază dezvoltatorii care scriu cod Django ușor de întreținut de cei care abuse de semnale și creează aplicații complicate și opace.