Kas yra Django signalai?

Question

Accepted Answer

**Signalai** yra Django observer šablono įgyvendimas — jie leidžia tam tikriems siuntėjams pranešti gavėjų grupei, kai įvyksta specifiniai **įvykiai** (pavyzdžiui, modelis išsaugojamas arba ištrinamas). Jie leidžia kurti **suporuotą** kodą: viena aplikacijos dalis reaguoja į įvykius kitoje dalyje be tiesioginės sąsajos.

## Įprasti įmontuoti signalai

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

## Gavėjo prijungimas prie signalo

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

Dekoratorius `@receiver` prijungia funkciją prie signalo tam tikram siuntėjui. Kai `User` išsaugomas, Django iškviečia šią funkciją — čia automatiškai sukuriamas susijęs `Profile`. Vėliava `created` atskiria sukūrimą nuo atnaujinimų.

## Tipiškas panaudojimo atvejis

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

Užsakymo kūrimo kodas lieka sukoncentruotas į užsakymus; el. pašto logika yra atskirai ir reaguoja į įvykį — išlaikant problemas suporuotomis.

## Kada signalai yra naudingi

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

## Svarbus įspėjimas: signalai gali užrukoti aiškumą

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

## Kodėl tai svarbu

Signalai yra naudingas Django funkcionalumas **kodui suporuoti** — leidžiant skirtingoms aplikacijos dalims reaguoti į įvykius (modelio išsaugojimai/trinimai, autentifikacijos įvykiai) be tiesioginių priklausomybių, kas yra vertinga dėl skersai besitęsiančių problemų, tokių kaip automatinis susijusių objektų kūrimas, podėlio negaliojimas, audito žurnalai ir reagavimas į įvykius keliose aplikacijos ribose.

Jų supratimas yra svarbus tiek **jas naudojant** atitinkamai, tiek **jas atpažinti** esamoje kodų bazėje (jos yra dažnas "kodėl tai nutiko?" sumaišymų šaltinis).

Tačiau tas, kas signalus paverčia ypač svarbia tema, yra **numantas sprendimas, kada juos naudoti**: nors jie leidžia elegantiškai suporuoti, jie taip pat sukuria **neapibrėžtą, "veiksmą-iš-tolo" elgesį**, kuris gali padaryti kodą sunkiau sekti ir atklysti (objekto išsaugojimas paslaptingai suaktyvina efektus, apibrėžtus kitur).

Brandi Django kūrėjai supranta šį kompromisą — naudodami signalus *tikrai* suporuoti (reaguojant skersai modulio/aplikacijos ribų į įvykius, kurių neturėtumėte susieti su šaltiniu) ir pirmenybę teikdami **aiškiam kodui** (tiesiogiai iškviečiant logiką, `save()` perrašant arba paslaugos funkcijomis naudojant), kai logika aiškiai priklauso tam pačiam srautui, nes aiškus kodas yra lengviau skaitomas ir sekiojamas.

Žinojimas, kaip signalai veikia (gavėjų prijungimas, `created` vėliava, įprasti signalai), jų legitimi naudojimo atvejai, ir, svarbiausia, **kada jų NENAUDOTI** (vengiant paslėpto, sunkiai atklydo elgesio) atspindi praktinį, patirtą supratimą, kuris atskiria kūrėjus, rašančius palaikomą Django kodą, nuo tų, kurie per daug naudoja signalus ir sukuria sudėtingas, neaiškias aplikacijas.