რა არის Django signals?

Question

Accepted Answer

**Signals** არის Django-ს განხორციელება observer pattern-ის — ისინი საშუალებას აძლევს გარკვეულ გამომგზავნელებს დააფიქსიროს სიმრავლე მიმღებების, როდესაც კონკრეტული **events** ხდება (როგორიცაა მოდელის შენახვა ან წაშლა). ისინი ხელმისაწვდომელი ხელმისაწვდომი კოდი: აპლიკაციის ერთი ნაწილი აგებულია მეორე ნაწილში მოვლენებზე უშუალო კავშირის გარეშე.

## პოპულარული ჩაშენებული 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
```

## მიმღების დაკავშირება 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)
```

`@receiver` დეკორატორი აკავშირებს ფუნქციას signal-ზე კონკრეტული გამომგზავნელისთვის. როდესაც `User` შენახულია, Django ეძახის ამ ფუნქციას — აქ, ავტომატურად შექმნის დაკავშირებული `Profile`. `created` დროშა განასხვავებს შექმნას განახლებისგან.

## ტიპიური 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
```

order-ის შექმნის კოდი ფოკუსირებული რჩება orders-ზე; email-ის logic ცალკე ცხოვრობს და აგებულია event-ზე — concerns-ის დიდი დეკოუპლირებით.

## როდესაც signals სასარგებლოა

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

## მნიშვნელოვანი ფრთხელი: signals შეიძლება აზიანეს 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.
```

## რატომ აქვს ეს მნიშვნელობა

Signals არის სასარგებლო Django მახასიათებელი **დეკოუპლირებისთვის** — საშუალებას აძლევს აპლიკაციის სხვადსხვა ნაწილი აღქმოს events (model saves/deletes, auth events) უშუალო დამოკიდებულების გარეშე, რაც ღირებული არის cross-cutting concerns-ისთვის, როგორიცაა დაკავშირებული ობიექტების ავტომატური შექმნა, cache invalidation, audit logging და events-ზე რეაგირება app boundaries-ის გასწვრივ.

მათი გაგება მნიშვნელოვანია როგორც *გამოყენების* ასპეტებიდან სათანადოდ და ასევე მათი აღიარება არსებულ codebases-ში (ისინი საერთო წყაროა "რატომ მოხდა ეს?" დაბნეულობის).

ამასთან, რა აქცევს signals განსაკუთრებით მნიშვნელოვან თემას არის **დახვეწილი განჩინება როდის გამოვიყენოთ ისინი**: სანამ ისინი ხელმისაწვდომელი დეკოუპლირებას ხელმუშაობენ, ისინი ასევე ქმნიან **implicit, "action-at-a-distance" behavior**, რომელიც კოდის კვლების რთულ ხდის და debug-ებს (object-ის შენახვა იდუმალი გამოუჯდება effects დაფიქსირებული სადმე სხვაგან).

მომწიფო Django დეველოპერი ესმის ეს გაცვლა — signals გამოიყენება *genuine* დეკოუპლირებისთვის (რეაგირება module/app boundaries-ის გასწვრივ events-ზე, რომელთა სკოპი არ უნდა მიამაგროთ source-ს) ხოლო აჯობებთ **explicit code** (ლოგიკის პირდაპირი გამოძახება, `save()`-ის override ან service functions-ის გამოყენება) როდესაც logic აშკარად მიეკუთვნება იმავე flow-ს, რადგან explicit code მეტი readable და traceable არის.

როგორ signals მუშაობს (receivers-ის დაკავშირება, `created` flag, common signals), მათი legitimate use cases, და critically **როდის არ გამოვიყენოთ ისინი** (hidden, hard-to-debug behavior-ის თავიდან აცილება) ასახავს პრაქტიკული, გამოცდილი გაგება, რომელიც განასხვავებს დეველოპერებს, რომელიც საინჟინრო Django კოდი წერენ მათ, რომელიც signals გამოჭარბებული გამოიყენებენ და შედეგად complex, opaque applications-ს ქმნიან.