Hvad er Django-signaler?

Question

Accepted Answer

**Signaler** er Djangos implementering af observatør-mønsteret — de lader bestemte afsendere underrette en gruppe modtagere, når specifikke **begivenheder** opstår (som når en model gemmes eller slettes). De muliggør **afkoblet** kode: en del af appen reagerer på begivenheder i en anden uden direkte kobling.

## Almindelige indbyggede signaler

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

## Forbindelse af en modtager til et 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)
```

Dekoratøren `@receiver` forbinder en funktion til et signal for en bestemt afsender. Når en `User` gemmes, kalder Django denne funktion — her oprettes automatisk en relateret `Profile`. Flaget `created` skelner mellem oprettelse og opdateringer.

## Et typisk 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
```

Koden, der opretter ordrer, fokuserer på ordrer; e-mail-logikken lever separat og reagerer på begivenheden — hvilket holder bekymringerne afkoblede.

## Hvornår signaler er nyttige

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

## Den vigtige advarsel: signaler kan skade klarhed

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

## Hvorfor det betyder noget

Signaler er en nyttig Django-funktion til **afkobling** af kode — der lader forskellige dele af en applikation reagere på begivenheder (model-gemte/sletninger, auth-begivenheder) uden direkte afhængigheder, hvilket er værdifuldt for tværgående bekymringer som automatisk oprettelse af relaterede objekter, cache-invalidering, revisionlogging og reaktion på begivenheder på tværs af app-grænser.

Det er vigtigt at forstå dem både for *at bruge* dem passende og for at genkende dem i eksisterende kodebaser (de er en almindelig kilde til "hvorfor skete dette?" forvirring).

Men det, der gør signaler til et særligt vigtigt emne, er **nuanceret vurdering af hvornår man skal bruge dem**: selvom de muliggør elegant afkobling, skaber de også **implicit, "handling-på-afstand"-adfærd**, der kan gøre koden sværere at følge og fejlrette (gemning af et objekt udløser mysterisk effekter defineret andetsteds).

Modne Django-udviklere forstår denne afvejning — bruger signaler til *ægte* afkobling (reaktion på tværs af modul-/app-grænser til begivenheder, du ikke burde koble til kilden) mens de foretrækker **eksplicit kode** (kalder logik direkte, tilsidesætter `save()`, eller bruger servicefunktioner), når logikken klart hører til i samme flow, fordi eksplicit kode er mere læsbar og sporbar.

At vide, hvordan signaler fungerer (forbindelse af modtagere, flaget `created`, almindelige signaler), deres legitime use cases, og især **hvornår man IKKE skal bruge dem** (undgå skjult, svært fejlretteligt adfærd) afspejler praktisk, erfaren forståelse, der skelner udviklere, der skriver vedligeholdelig Django-kode, fra dem, der misbruger signaler og skaber usammenhængende, uigennemsigtige applikationer.