O que são sinais Django?

Question

Accepted Answer

**Sinais** são a implementação do padrão observer do Django — eles permitem que certos emissores notifiquem um conjunto de receptores quando **eventos** específicos ocorrem (como um modelo sendo salvo ou deletado). Eles habilitam código **desacoplado**: uma parte da aplicação reage a eventos em outra sem acoplamento direto.

## Sinais integrados comuns

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

## Conectando um receptor a um sinal

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

O decorador `@receiver` conecta uma função a um sinal para um emissor específico. Quando um `User` é salvo, Django chama essa função — aqui, criando automaticamente um `Profile` relacionado. O sinalizador `created` distingue criação de atualizações.

## Um caso de uso típico

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

O código que cria pedidos permanece focado em pedidos; a lógica de email vive separadamente e reage ao evento — mantendo as responsabilidades desacopladas.

## Quando sinais são úteis

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

## A ressalva importante: sinais podem prejudicar a clareza

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

## Por que isso importa

Sinais são um recurso útil do Django para **desacoplamento** de código — permitindo que diferentes partes de uma aplicação reajam a eventos (salvamentos/exclusões de modelos, eventos de autenticação) sem dependências diretas, o que é valioso para responsabilidades transversais como criação automática de objetos relacionados, invalidação de cache, registro de auditoria e reação a eventos através de limites de aplicação.

Entender sinais é importante tanto para *usá-los* apropriadamente quanto para reconhecê-los em bases de código existentes (eles são uma fonte comum de confusão "por que isso aconteceu?").
"},
 "answer": "Porém, o que torna sinais um tópico particularmente importante é o **julgamento nuançado sobre quando usá-los**: enquanto eles habilitam desacoplamento elegante, também criam comportamento **implícito de "ação à distância"** que pode tornar o código mais difícil de acompanhar e depurar (salvar um objeto misteriosamente dispara efeitos definidos em outro lugar).

Desenvolvedores Django experientes entendem essa compensação — usando sinais para *genuíno* desacoplamento (reagindo através de limites de módulo/aplicação a eventos aos quais você não deveria se acoplar à fonte) enquanto preferem **código explícito** (chamando lógica diretamente, sobrescrevendo `save()` ou usando funções de serviço) quando a lógica claramente pertence ao mesmo fluxo, porque código explícito é mais legível e rastreável.

Saber como sinais funcionam (conectar receptores, o sinalizador `created`, sinais comuns), seus casos de uso legítimos e crucialmente **quando NÃO usá-los** (evitando comportamento oculto e difícil de depurar) reflete compreensão prática e experiente que distingue desenvolvedores que escrevem código Django mantível daqueles que abusam de sinais e criam aplicações enredadas e opacas."}}}]}}}}]}}}}]}}}}]}}}}]}}}}