Apa itu Django signals?

Question

Accepted Answer

**Signals** adalah implementasi Django terhadap observer pattern — mereka memungkinkan pengirim tertentu memberitahu serangkaian penerima ketika **event** spesifik terjadi (seperti model disimpan atau dihapus). Mereka memungkinkan kode yang **decoupled**: satu bagian aplikasi bereaksi terhadap event di bagian lain tanpa coupling langsung.

## Signals built-in yang umum

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

## Menghubungkan receiver ke 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` menghubungkan fungsi ke signal untuk sender spesifik. Ketika `User` disimpan, Django memanggil fungsi ini — di sini, auto-membuat `Profile` terkait. Flag `created` membedakan pembuatan dari update.

## Use case yang khas

```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 pembuatan pesanan tetap fokus pada pesanan; logika email tinggal terpisah dan bereaksi terhadap event — menjaga concern tetap decoupled.

## Kapan signals berguna

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

## Caveat penting: signals dapat merusak 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 ini penting

Signals adalah fitur Django yang berguna untuk **decoupling** kode — membiarkan berbagai bagian aplikasi bereaksi terhadap event (model saves/deletes, auth events) tanpa dependency langsung, yang berharga untuk cross-cutting concerns seperti auto-membuat object terkait, cache invalidation, audit logging, dan bereaksi terhadap event di seluruh boundary aplikasi.

Memahami mereka penting baik untuk *menggunakan* mereka dengan tepat maupun untuk mengenali mereka dalam codebase yang ada (mereka adalah sumber umum dari kebingungan "mengapa ini terjadi?").
" namun, yang membuat signals menjadi topik yang sangat penting adalah **penilaian bernuansa tentang kapan menggunakannya**: sementara mereka memungkinkan decoupling yang elegan, mereka juga menciptakan **implicit, "action-at-a-distance" behavior** yang dapat membuat kode lebih sulit diikuti dan di-debug (menyimpan object secara misterius memicu efek yang didefinisikan di tempat lain).

Developer Django yang matang memahami trade-off ini — menggunakan signals untuk *genuine* decoupling (bereaksi di seluruh module/app boundary terhadap event yang tidak seharusnya Anda couple ke sumber) sambil lebih suka **explicit code** (memanggil logika langsung, override `save()`, atau menggunakan service functions) ketika logika jelas milik alur yang sama, karena explicit code lebih readable dan traceable.

Mengetahui bagaimana signals bekerja (menghubungkan receivers, flag `created`, signals umum), use case legitimate mereka, dan sangat penting **kapan TIDAK menggunakannya** (menghindari hidden, hard-to-debug behavior) mencerminkan pemahaman praktis dan berpengalaman yang membedakan developer yang menulis Django code yang maintainable dari mereka yang overuse signals dan menciptakan aplikasi yang tangled dan opaque.