Czym są sygnały Django?

Question

Accepted Answer

**Sygnały** to implementacja wzorca obserwatora w Django — pozwalają określonym nadawcom powiadomić zbiór odbiorców, gdy zachodzą określone **zdarzenia** (takie jak zapisanie lub usunięcie modelu). Umożliwiają **rozprzężony** kod: jedna część aplikacji reaguje na zdarzenia w innej bez bezpośredniego sprzężenia.

## Typowe wbudowane sygnały

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

## Łączenie odbiorcy z sygnałem

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

Dekorator `@receiver` łączy funkcję z sygnałem dla określonego nadawcy. Gdy `User` jest zapisany, Django wywołuje tę funkcję — tutaj automatycznie tworzy powiązany `Profile`. Flaga `created` rozróżnia tworzenie od aktualizacji.

## Typowy przypadek użycia

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

Kod tworzący zamówienie pozostaje skoncentrowany na zamówieniach; logika wysyłania e-maili żyje osobno i reaguje na zdarzenie — zachowując rozdzielenie zagadnień.

## Kiedy sygnały są przydatne

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

## Ważne zastrzeżenie: sygnały mogą zaszkodzić przejrzystości

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

## Dlaczego to ważne

Sygnały są przydatną funkcją Django do **rozprzęzenia** kodu — umożliwiające różnym częściom aplikacji reagowanie na zdarzenia (zapisanie/usunięcie modeli, zdarzenia autentykacji) bez bezpośrednich zależności, co jest cenne dla zagadnień przekrojowych, takich jak automatyczne tworzenie powiązanych obiektów, unieważnianie pamięci podręcznej, rejestrowanie audytu i reagowanie na zdarzenia w granicach aplikacji.

Zrozumienie ich jest ważne zarówno do *właściwego* ich używania, jak i do rozpoznawania ich w istniejących bazach kodu (są częstym źródłem zamieszania „dlaczego to się stało?")

Jednak to, co czyni sygnały szczególnie ważnym zagadnieniem, to **niuansowana ocena, kiedy ich używać**: choć umożliwiają eleganckie rozprzęzenie, tworzą również **niejawne, "działające na odległość" zachowanie**, które może utrudniać śledzenie i debugowanie kodu (zapisanie obiektu tajemniczo uruchamia efekty zdefiniowane gdzie indziej).

Dojrzali programiści Django rozumieją ten kompromis — używając sygnałów do *właściwego* rozprzęzenia (reagowanie w granicach modułu/aplikacji na zdarzenia, do których nie powinni być sprzężeni ze źródłem), preferując **jawny kod** (bezpośrednie wywoływanie logiki, nadpisywanie `save()` lub używanie funkcji serwisowych), gdy logika wyraźnie należy do tego samego przepływu, ponieważ jawny kod jest bardziej czytelny i łatwy do śledzenia.

Wiedza na temat działania sygnałów (łączenie odbiorców, flaga `created`, typowe sygnały), ich uzasadnionych przypadków użycia i przede wszystkim **kiedy ich NIE używać** (unikanie ukrytego, trudnego do debugowania zachowania) odzwierciedla praktyczne, doświadczone zrozumienie, które rozróżnia programistów piszących łatwe w utrzymaniu aplikacje Django od tych, którzy nadużywają sygnałów i tworzą splątane, nieprzejrzyste aplikacje.