Vad är Django-signaler?

Question

Accepted Answer

**Signaler** är Djangos implementering av observer-mönstret — de låter vissa avsändare meddela en uppsättning mottagare när specifika **händelser** inträffar (som när en modell sparas eller tas bort). De möjliggör **lös koppling** av kod: en del av appen reagerar på händelser i en annan del utan direkt koppling.

## Vanliga inbyggda 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
```

## Ansluta en mottagare till en 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)
```

Dekoratorn `@receiver` ansluter en funktion till en signal för en specifik avsändare. När en `User` sparas, anropar Django denna funktion — här skapas automatiskt en relaterad `Profile`. Flaggan `created` skiljer skapande från uppdateringar.

## Ett typiskt användningsfall

```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 skapar order fokuserar på order; e-postlogiken ligger separat och reagerar på händelsen — vilket håller ansvaret uppdelat.

## När signaler är användbara

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

## Det viktiga förbehållet: signaler kan skada tydligheten

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

## Varför det är viktigt

Signaler är en användbar Django-funktion för **lös koppling** av kod — som låter olika delar av en applikation reagera på händelser (modellsparning/borttagning, autentiseringshändelser) utan direkta beroenden, vilket är värdefullt för tvärsnittande problem som autoskapande av relaterade objekt, cacheogiltigörande, granskningsmärkning och reaktion på händelser över appgränser.

Att förstå dem är viktigt både för att *använda* dem på lämpligt sätt och för att känna igen dem i befintliga kodbaser (de är en vanlig källa till "varför hände detta?" förvirring).

Det som gör signaler till ett särskilt viktigt ämne är dock det **nyanserade bedömandet om när de ska användas**: medan de möjliggör elegant lös koppling, skapar de också **underförstådd, "handling på avstånd" beteende** som kan göra koden svårare att följa och felsöka (sparning av ett objekt kan mystiskt utlösa effekter definierade någon annanstans).

Ervarna Django-utvecklare förstår denna kompromiss — använder signaler för *genuin* lös koppling (reaktion över modul-/appgränser på händelser som du inte bör koppla till källan) medan de föredrar **explicit kod** (direkt anrop av logik, åsidosättande av `save()` eller användning av servicefunktioner) när logiken tydligt hör hemma i samma flöde, eftersom explicit kod är mer läsbar och spårbar.

Att veta hur signaler fungerar (anslutning av mottagare, flaggan `created`, vanliga signaler), deras legitima användningsfall och kritiskt **när man INTE ska använda dem** (undvika dold, svårfelsökbar beteende) återspeglar praktisk, erfaren förståelse som skiljer utvecklare som skriver underhållbar Django-kod från de som överanvänder signaler och skapar rörig, opak applikationer.