Hva er Django-signaler?

Question

Accepted Answer

**Signaler** er Djangos implementering av observer-mønsteret — de lar visse sendere varsle et sett med mottakere når spesifikke **hendelser** oppstår (som når en modell blir lagret eller slettet). De muliggjør **løstkoblet** kode: en del av appen reagerer på hendelser i en annen uten direkte kobling.

## Vanlige innebygde 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
```

## Koble en mottaker 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)
```

`@receiver`-dekoratøren kobler en funksjon til et signal for en spesifikk sender. Når en `User` blir lagret, kaller Django denne funksjonen — her opprettet automatisk en relatert `Profile`. Flagget `created` skiller opprettelse fra oppdateringer.

## Et typisk brukstilfelle

```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 som oppretter ordrer forblir fokusert på ordrer; e-postlogikken lever separat og reagerer på hendelsen — noe som holder bekymringer løstkoblet.

## Nå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
```

## En viktig advarsel: signaler kan skade klarhet

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

Signaler er en nyttig Django-funksjon for **løstkoblet** kode — som lar ulike deler av en applikasjon reagere på hendelser (modelllagringer/slettinger, auth-hendelser) uten direkte avhengigheter, noe som er verdifullt for tversgående bekymringer som automatisk opprettelse av relaterte objekter, cache-ugyldiggjøring, revisjonslogging og reaksjon på hendelser på tvers av appgrenser.

Å forstå dem er viktig både for *å bruke* dem på riktig måte og for å gjenkjenne dem i eksisterende kodebaser (de er en vanlig kilde til "hvorfor skjedde dette?" forvirring).

Men det som gjør signaler til et særlig viktig tema er den **nyanserte dømmekraften om når de skal brukes**: mens de muliggjør elegant løstkobling, skaper de også **implisitt, "handling-på-avstand"-atferd** som kan gjøre kode vanskeligere å følge og debugge (lagring av et objekt utløser mystisk effekter definert andre steder).

Modne Django-utviklere forstår denne avveiningen — bruker signaler for *genuint* løstkoblet kode (reagerer på tvers av modul-/app-grenser på hendelser du ikke bør koble til kilden) mens de foretrekker **eksplisitt kode** (kaller logikk direkte, overstyrer `save()`, eller bruker service-funksjoner) når logikken klart tilhører samme flyt, fordi eksplisitt kode er mer lesbar og sporbar.

Å vite hvordan signaler fungerer (koble mottakere, `created`-flagget, vanlige signaler), deres legitime brukstilfeller, og avgjørende **når NOT å bruke dem** (unngår skjult, vanskelig-å-debugge-atferd) gjenspeiler praktisk, erfaren forståelse som skiller utviklere som skriver vedlikeholdbar Django-kode fra de som overbruker signaler og skaper rotete, ugjennomsiktige applikasjoner.