Qu'est-ce que les signaux Django ?

Question

Accepted Answer

Les **signaux** sont l'implémentation par Django du pattern observateur — ils permettent à certains émetteurs de notifier un ensemble de récepteurs lorsque des **événements** spécifiques se produisent (comme l'enregistrement ou la suppression d'un modèle). Ils permettent un code **découplé** : une partie de l'application réagit aux événements d'une autre sans couplage direct.

## Signaux intégrés courants

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

## Connecter un récepteur à un 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)
```

Le décorateur `@receiver` connecte une fonction à un signal pour un émetteur spécifique. Quand un `User` est enregistré, Django appelle cette fonction — ici, créant automatiquement un `Profile` associé. Le drapeau `created` distingue la création des mises à jour.

## Un cas d'usage typique

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

Le code de création de commande reste concentré sur les commandes ; la logique d'e-mail vit séparément et réagit à l'événement — gardant les préoccupations découplées.

## Quand les signaux sont utiles

```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 mise en garde importante : les signaux peuvent affecter la clarté

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

## Pourquoi c'est important

Les signaux sont une fonctionnalité Django utile pour **découpler** le code — permettant à différentes parties d'une application de réagir aux événements (sauvegardes/suppressions de modèles, événements d'authentification) sans dépendances directes, ce qui est précieux pour les préoccupations transversales comme la création automatique d'objets associés, l'invalidation du cache, l'audit, et la réaction aux événements à travers les limites des applications.

Les comprendre est important à la fois pour les *utiliser* correctement et pour les reconnaître dans les bases de code existantes (ils sont une source courante de confusion « pourquoi cela s'est-il produit ? »).

Cependant, ce qui rend les signaux un sujet particulièrement important est le **jugement nuancé sur quand les utiliser** : bien qu'ils permettent un découplage élégant, ils créent aussi un comportement **implicite, « action-à-distance »** qui peut rendre le code plus difficile à suivre et à déboguer (l'enregistrement d'un objet déclenche mystérieusement des effets définis ailleurs).

Les développeurs Django expérimentés comprennent ce compromis — utilisant les signaux pour un *vrai* découplage (réagir à travers les limites de modules/applications à des événements auxquels vous ne devriez pas coupler la source) tout en préférant un **code explicite** (appeler la logique directement, surcharger `save()`, ou utiliser des fonctions de service) quand la logique appartient clairement au même flux, car le code explicite est plus lisible et traçable.

Savoir comment fonctionnent les signaux (connecter des récepteurs, le drapeau `created`, les signaux courants), leurs cas d'usage légitimes, et crucially **quand NE PAS les utiliser** (éviter un comportement caché et difficile à déboguer) reflète une compréhension pratique et expérimentée qui distingue les développeurs qui écrivent du code Django maintenable de ceux qui surutilisent les signaux et créent des applications enchevêtrées et opaques.