Apa iku Django signals?

Question

Accepted Answer

**Signals** minangka implementasi Django saka observer pattern — padha ngicini amanah-amanah tartamtu bisa ngabari set saka penerima nalika **events** tartamtu kelakon (kaya model disimpen utawa dihapus). Padha ngidini **decoupled** code: siji bagean saka app bisa ngreaski events ing bagean liyane tanpa coupling langsung.

## Common built-in signals

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

## Connecting a receiver to a 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)
```

Decorator `@receiver` nglinkake fungsi menyang signal kanggo sender spesifik. Nalika `User` disimpen, Django nggawe fungsi iki — ing kene, auto-creating related `Profile`. Flag `created` mbedakke creation saka updates.

## A typical use case

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

Kode order-creating tetep fokus ing orders; logika email manggon terpisah lan ngreaski event — ndadekke concerns decoupled.

## When signals are useful

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

## The important caveat: signals can hurt clarity

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

## Mengapa iki penting

Signals minangka fitur Django sing berguna kanggo **decoupling** code — ngidini bagean-bagean beda saka aplikasi bisa ngreaski events (model saves/deletes, auth events) tanpa direct dependencies, sing berharga kanggo cross-cutting concerns kaya auto-creating related objects, cache invalidation, audit logging, lan ngreaski events sa pambatas app.

Pamahaman babagan padha penting kanggo *using* padha kanthi trep lan kanggo ngkenal padha ing existing codebases (padha minangka sumber umum saka "mengapa iki kelakon?" kebingungan).
");Nanging, apa sing ndadekke signals topik sing khusus penting minangka **nuanced judgment babagan kapan nggunaake padha**: nalika padha ngidini elegant decoupling, padha uga njiptaake **implicit, "action-at-a-distance" behavior** sing bisa ndadekke code luwih angel diikuti lan debug (nyimpen object kanthi rahasia ngudani effects sing diendalake ing papan liya).

Matured Django developers ngerti trade-off iki — nggunaake signals kanggo *genuine* decoupling (ngreaski sa pambatas module/app menyang events sing kudu sampean cupet coupling menyang source) nalika preferring **explicit code** (nggawe logika langsung, override `save()`, utawa nggunaake service functions) nalika logika jelas belongs ing aliran sing sama, amarga explicit code luwih readable lan traceable.

Ngerti kepiye signals ngkaske (nglinkake receivers, flag `created`, common signals), legitimate use cases, lan crucially **kapan TIDAK nggunaake padha** (ngindari hidden, hard-to-debug behavior) ngrefleksake practical, experienced understanding sing mbedakke developers sing nulis maintainable Django code saka padha sing overuse signals lan njiptaake tangled, opaque applications.