Apakah signal Django?

Question

Accepted Answer

**Signal** ialah pelaksanaan corak pemerhati (observer pattern) Django — ia membolehkan penghantar tertentu memberitahu satu set penerima apabila **peristiwa** khusus berlaku (seperti model disimpan atau dipadam). Ia membolehkan kod yang **terpisah (decoupled)**: satu bahagian aplikasi bertindak balas terhadap peristiwa di bahagian lain tanpa gandingan langsung.

## Signal terbina dalam yang biasa

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

## Menyambungkan penerima 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` menyambungkan fungsi ke signal untuk penghantar tertentu. Apabila `User` disimpan, Django memanggil fungsi ini — di sini, mencipta `Profile` berkaitan secara automatik. Bendera `created` membezakan penciptaan daripada kemas kini.

## Kes penggunaan biasa

```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 yang mencipta Order kekal tertumpu pada pesanan; logik email berada secara berasingan dan bertindak balas terhadap peristiwa — mengekalkan tanggungjawab terpisah.

## Bila signal 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
```

## Peringatan penting: signal boleh menjejaskan kejelasan

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

Signal ialah ciri Django yang berguna untuk **memisahkan (decoupling)** kod — membolehkan bahagian aplikasi yang berbeza bertindak balas terhadap peristiwa (penyimpanan/pemadaman model, peristiwa auth) tanpa kebergantungan langsung, yang bernilai untuk tanggungjawab silang seperti mencipta objek berkaitan secara automatik, pembatalan cache, pengelogan audit, dan bertindak balas terhadap peristiwa merentasi sempadan aplikasi.

Memahaminya adalah penting kedua-dua untuk *menggunakannya* dengan sewajarnya dan untuk mengenalinya dalam pangkalan kod sedia ada (ia merupakan punca biasa kekeliruan "mengapa ini berlaku?").

Walau bagaimanapun, apa yang menjadikan signal topik yang amat penting ialah **pertimbangan bernuansa tentang bila untuk menggunakannya**: walaupun ia membolehkan pemisahan yang elegan, ia juga mewujudkan tingkah laku **tersirat, "tindakan dari jauh"** yang boleh menjadikan kod lebih sukar diikuti dan dinyahpepijat (menyimpan objek secara misteri mencetuskan kesan yang ditakrifkan di tempat lain).

Pembangun Django yang matang memahami kompromi ini — menggunakan signal untuk pemisahan yang *tulen* (bertindak balas merentasi sempadan modul/aplikasi terhadap peristiwa yang tidak patut anda gandingkan dengan sumbernya) sambil mengutamakan **kod eksplisit** (memanggil logik secara langsung, menggantikan `save()`, atau menggunakan fungsi perkhidmatan) apabila logik itu jelas tergolong dalam aliran yang sama, kerana kod eksplisit lebih mudah dibaca dan dikesan.

Mengetahui cara signal berfungsi (menyambung penerima, bendera `created`, signal biasa), kes penggunaannya yang sah, dan yang penting **bila TIDAK menggunakannya** (mengelakkan tingkah laku tersembunyi yang sukar dinyahpepijat) mencerminkan pemahaman praktikal yang berpengalaman yang membezakan pembangun yang menulis kod Django yang boleh diselenggara daripada mereka yang terlalu menggunakan signal dan mencipta aplikasi yang berbelit dan kabur.