¿Qué son las señales de Django?

Question

Accepted Answer

**Signals** (señales) son la implementación de Django del patrón observer — permiten que ciertos remitentes notifiquen a un conjunto de receptores cuando ocurren eventos específicos (como que un modelo se guarde o se elimine). Permiten código **desacoplado**: una parte de la app reacciona a eventos en otra sin acoplamiento directo.

## Señales integradas comunes

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

## Conectar un receptor a una señal

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

El decorador `@receiver` conecta una función a una señal para un remitente específico. Cuando se guarda un `User`, Django llama a esta función — aquí, creando automáticamente un `Profile` relacionado. La bandera `created` distingue la creación de las actualizaciones.

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

El código que crea órdenes se mantiene enfocado en órdenes; la lógica de email vive por separado y reacciona al evento — manteniendo las preocupaciones desacopladas.

## Cuándo las señales son útiles

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

## La advertencia importante: las señales pueden afectar la claridad

```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 qué es importante

Las señales son una característica útil de Django para **desacoplar** código — permitiendo que diferentes partes de una aplicación reaccionen a eventos (guardados/eliminaciones de modelos, eventos de autenticación) sin dependencias directas, lo cual es valioso para preocupaciones transversales como crear automáticamente objetos relacionados, invalidación de caché, auditoría de registros, y reaccionar a eventos a través de límites de app.

Comprender las señales es importante tanto para *usarlas* apropiadamente como para reconocerlas en bases de código existentes (son una fuente común de confusión "¿por qué pasó esto?").

Sin embargo, lo que hace que las señales sean un tema particularmente importante es el **juicio matizado sobre cuándo usarlas**: aunque permiten desacoplamiento elegante, también crean comportamiento **implícito, "acción a distancia"** que puede hacer que el código sea más difícil de seguir y depurar (guardar un objeto misteriosamente desencadena efectos definidos en otro lugar).

Los desarrolladores de Django experimentados entienden este equilibrio — usando señales para *desacoplamiento genuino* (reaccionar a través de límites de módulo/app a eventos a los cuales no deberías acoplar la fuente) mientras prefieren **código explícito** (llamar a la lógica directamente, sobrescribir `save()`, o usar funciones de servicio) cuando la lógica claramente pertenece al mismo flujo, porque el código explícito es más legible y rastreable.

Saber cómo funcionan las señales (conectar receptores, la bandera `created`, señales comunes), sus casos de uso legítimos, y crucialmente **cuándo NO usarlas** (evitar comportamiento oculto y difícil de depurar) refleja una comprensión práctica y experimentada que distingue a desarrolladores que escriben código Django mantenible de aquellos que abusan de las señales y crean aplicaciones enredadas y opacas.