Mik a Django signalok?

Question

Accepted Answer

A **signalok** a Django megvalósítása az observer pattern-nek — lehetővé teszik, hogy bizonyos feladók értesítsenek egy csoportot az érdeklődőknek, amikor specifikus **események** történnek (például egy modell mentése vagy törlése). Lehetővé teszik a **lazán csatolt** kódot: az alkalmazás egyik része reagál egy másik részben történő eseményekre közvetlen csatolódás nélkül.

## Gyakori beépített signalok

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

## Vevő csatlakoztatása egy signalhoz

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

A `@receiver` dekorátor egy függvényt csatlakoztat egy signalhoz egy specifikus feladóhoz. Amikor egy `User` mentésre kerül, a Django meghívja ezt a függvényt — itt egy kapcsolódó `Profile` automatikus létrehozása történik. A `created` jelzőfény különbséget tesz a létrehozás és a módosítás között.

## Egy tipikus felhasználási eset

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

A rendelés-létrehozó kód a rendelésekre koncentrál; az e-mail logika külön él és az eseményre reagál — így a problémák lazán csatoltak maradnak.

## Mikor hasznosak a signalok

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

## A fontos figyelmeztetés: a signalok ronthatják az átláthatóságot

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

## Miért fontos

A signalok egy hasznos Django-függvény a kód **lazán csatolásához** — lehetővé teszik, hogy az alkalmazás különböző részei reagáljanak az eseményekre (modell mentése/törlése, hitelesítési események) közvetlen függőségek nélkül, ami értékes a kereszttudatlan problémákhoz, mint az automatikus kapcsolódó objektumok létrehozása, gyorsítótár-invalidálás, audit naplózás és események közötti határok között való reagálás.

Fontos megérteni őket mind az *alkalmazott* használatukhoz és az *ismerés* tekintetében a meglévő kódbázisokban (gyakori forrása az "Miért történt ez?" zavarodottságnak).

Azonban az a tény, ami a signalokat különösen fontos témává teszi, az a **árnyalt ítélet arról, hogy mikor kell őket használni**: míg elegáns lazulást biztosítanak, olyan **implicit, "távolról működő" viselkedést** is létrehoznak, amely nehezebb az kód követésétét és hibakeresését (egy objektum mentése rejtélyes hatásokat vált ki, amelyeket máshol határoztak meg).

A tapasztalt Django fejlesztők megértik ezt a kompromisszumot — olyan signalokra használják őket, amelyek *valódi* lazulást biztosítanak (modul/alkalmazás határok között reagálnak olyan eseményekre, amelyekhez nem szabad a forrásforrást összekapcsolni), miközben az **explicit kódot** részesítik előnyben (közvetlenül logikát hívnak meg, felülírják a `save()` függvényt, vagy szolgáltatási funkciókat használnak), ha a logika egyértelműen ugyanabba a folyamatba tartozik, mert az explicit kód olvashatóbb és nyomonkövethetőbb.

Annak ismerete, hogy a signalok hogyan működnek (vevők csatlakoztatása, a `created` jelzőfény, közös signalok), azok legitim felhasználási esetei, és döntően **mikor NE használjuk őket** (elkerülve a rejtett, nehezen hibakeresendő viselkedést) azt tükrözi a gyakorlati, tapasztalt megértést, amely megkülönbözteti a karbantartható Django kódot írók fejlesztőket azoktól, akik túlzásosan használják a signalokat és zavaros, átláthatatlan alkalmazásokat hoznak létre.