Wat zijn Django-signalen?

Question

Accepted Answer

**Signalen** zijn Django's implementatie van het observer-patroon — ze laten bepaalde afzenders een set ontvangers op de hoogte stellen wanneer specifieke **events** plaatsvinden (zoals een model dat wordt opgeslagen of verwijderd). Ze maken **ontkoppelde** code mogelijk: een deel van de app reageert op events in een ander deel zonder directe afhankelijkheid.

## Veelgebruikte ingebouwde signalen

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

## Een ontvanger met een signaal verbinden

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

De `@receiver`-decorator verbindt een functie met een signaal voor een specifieke afzender. Wanneer een `User` wordt opgeslagen, roept Django deze functie aan — hier wordt automatisch een gerelateerd `Profile` aangemaakt. De `created`-vlag onderscheidt aanmaken van updates.

## Een typisch 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
```

De order-aanmaakcode blijft gericht op orders; de e-maillogica leeft apart en reageert op het event — wat zorgt voor ontkoppelde concerns.

## Wanneer signalen nuttig zijn

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

## De belangrijke waarschuwing: signalen kunnen duidelijkheid schaden

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

## Waarom het belangrijk is

Signalen zijn een nuttige Django-functie voor **ontkoppeling** van code — waardoor verschillende delen van een applicatie kunnen reageren op events (model saves/deletes, auth events) zonder directe afhankelijkheden, wat waardevol is voor cross-cutting concerns zoals automatisch aanmaken van gerelateerde objecten, cache invalidering, audit logging, en reageren op events over app-grenzen heen.

Het begrijpen ervan is belangrijk voor zowel het *correct* gebruiken ervan als het herkennen ervan in bestaande codebases (ze zijn een veel voorkomende bron van "waarom gebeurde dit?" verwarring).

Het wat signalen echter een bijzonder belangrijk onderwerp maakt, is het **genuanceerde oordeel over wanneer ze te gebruiken**: hoewel ze elegante ontkoppeling mogelijk maken, creëren ze ook **impliciete, "action-at-a-distance"-gedrag** dat code moeilijker te volgen en debuggen kan maken (het opslaan van een object triggert mysterieus effecten die elders zijn gedefinieerd).

Ervaren Django-ontwikkelaars begrijpen deze afweging — signalen gebruiken voor *echte* ontkoppeling (reageren over module/app-grenzen op events waar je niet aan de bron gekoppeld zou moeten zijn) terwijl je **expliciete code** prefereert (logica rechtstreeks aanroepen, `save()` overschrijven, of service-functies gebruiken) wanneer de logica duidelijk in dezelfde stroom thuishoort, omdat expliciete code beter leesbaar en traceerbaar is.

Weten hoe signalen werken (ontvangers verbinden, de `created`-vlag, veelgebruikte signalen), hun legitieme use cases, en cruciaal **wanneer ze NIET te gebruiken** (vermijden van verborgen, moeilijk te debuggen gedrag) weerspiegelt praktische, ervaren kennis die ontwikkelaars die onderhoudsbare Django-code schrijven, onderscheidt van degenen die signalen overgebruiken en verwarde, ondoorzichtige applicaties creëren.