Cosa sono i segnali Django?

Question

Accepted Answer

**Signals** sono l'implementazione di Django del pattern observer — permettono a determinati mittenti di notificare un insieme di ricevitori quando si verificano eventi specifici (come quando un modello viene salvato o eliminato). Abilitano codice **disaccoppiato**: una parte dell'app reagisce a eventi in un'altra senza accoppiamento diretto.

## Segnali built-in comuni

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

## Connettere un ricevitore a un segnale

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

Il decoratore `@receiver` connette una funzione a un segnale per uno specifico mittente. Quando un `User` viene salvato, Django chiama questa funzione — qui, creando automaticamente un `Profile` correlato. Il flag `created` distingue la creazione dagli aggiornamenti.

## Un caso d'uso tipico

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

Il codice che crea gli ordini rimane focalizzato sugli ordini; la logica email vive separatamente e reagisce all'evento — mantenendo i compiti disaccoppiati.

## Quando i segnali sono utili

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

## La caveat importante: i segnali possono compromettere la chiarezza

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

## Perché è importante

I segnali sono una funzionalità utile di Django per **disaccoppiare** il codice — permettendo a diverse parti di un'applicazione di reagire a eventi (salvataggio/eliminazione di modelli, eventi di autenticazione) senza dipendenze dirette, il che è prezioso per problemi trasversali come la creazione automatica di oggetti correlati, l'invalidazione della cache, il logging di audit e la reazione a eventi attraversi confini di app.

Comprendere questi segnali è importante sia per *usarli* appropriatamente che per riconoscerli nei codebase esistenti (sono una fonte comune di confusione "perché è successo?").

Tuttavia, ciò che rende i segnali un argomento particolarmente importante è il **giudizio sfumato su quando usarli**: sebbene abilitino un disaccoppiamento elegante, creano anche comportamenti **impliciti, "action-at-a-distance"** che possono rendere il codice più difficile da seguire e debuggare (salvare un oggetto misticamente attiva effetti definiti altrove).

Gli sviluppatori Django esperti capiscono questo compromesso — usando i segnali per un *vero* disaccoppiamento (reagire attraverso confini di moduli/app a eventi a cui non dovresti accoppiare la fonte) mentre preferiscono **codice esplicito** (chiamare la logica direttamente, sovrascrivere `save()`, o usare funzioni di servizio) quando la logica appartiene chiaramente allo stesso flusso, perché il codice esplicito è più leggibile e tracciabile.

Sapere come funzionano i segnali (connettere ricevitori, il flag `created`, i segnali comuni), i loro casi d'uso legittimi, e crucialmente **quando NON usarli** (evitando comportamenti nascosti e difficili da debuggare) riflette una comprensione pratica ed esperta che distingue gli sviluppatori che scrivono codice Django mantenibile da chi abusa dei segnali e crea applicazioni intricate e opache.