Signals in Django

Signals provide a way to respond to actions occurring within an application. They allow tasks like logging, cache invalidation, or automatic data updates to execute without tightly coupling the code. Signals follow a publish-subscribe pattern, where a sender broadcasts an event and receivers handle it.

Built-in Signals

Django provides around 20 built-in signals, organized by category. They trigger at specific points in the framework lifecycle, allowing applications to respond to events such as model saves, deletions, or request/response processing.

Model Signals

Request/Response Signals

Database Signals

Connect to these via decorators or methods. Always specify sender for efficiency.

Connecting and Disconnecting Receivers

Signals in Django need receiver functions to respond when an event is triggered. Receivers can be connected and disconnected using decorators or the connect()/disconnect() methods.

1. Using Decorators

• @receiver(signal, sender=Model) connects the function to the signal.
• sender ensures the receiver only listens to that specific model, improving efficiency.

2. Using connect() Method

3. Disconnecting Receivers

To stop a receiver from listening:

post_save.disconnect(create_profile, sender=CustomUser)

This can be useful in tests or temporary signal handling. Always specify the sender when connecting to signals. It reduces unnecessary function calls and improves performance.

Sending Signals

Built-in signals fire automatically, but custom signals can be sent manually when needed.

• send(): Fails fast if a receiver raises an exception.
• send_robust(): Continues sending to other receivers; exceptions are returned in a SignalError list.
• Signal receivers always receive the sender, which is the object or class sending the signal, and kwargs, containing any additional data passed during send().

This allows custom events to trigger multiple receivers in a clean and decoupled way.

Signals Working

Django signals allow decoupled components to get notified when certain actions occur. The flow works as follows:

1. Define or Use a Signal

• Use a built-in signal like post_save or define a custom signal using Signal().

2. Connect a Receiver

• A receiver is a function or method that reacts when the signal is sent.
• Connect it using the @receiver decorator or signal.connect() method.

3. Send the Signal

• Built-in signals are fired automatically by Django.
• Custom signals are fired manually using send() or send_robust().

4. Receiver Executes

• The connected receiver receives the sender and any additional kwargs passed.
• It performs the intended action (e.g., logging, updating related objects, sending notifications).

Example: Auto-Creating User Profile with Django Signals

Consider a project named 'userprofile_project' having an app named 'users'.

Automatically create a profile for every new user upon registration.

models.py: Each user has a profile linked via a one-to-one relationship.

views.py:

forms.py: Defines forms for user registration and profile updates.

signals.py(Using receiver method): Automatically creates and saves a profile when a User is created.

When the User model is saved, a signal called create_profile is fired. This signal creates a Profile instance with a foreign key pointing to the saved User instance. The save_profile signal ensures that the profile instance is also saved after the user is saved.

Signals can also be loaded automatically using AppConfig:

The signal resides in the signals.py file of the app.

If user is created:

Then his profile is automatically created:

Check it in admin view: 

Using pre_save with Receiver Method

The pre_save signal is triggered immediately before a model's save() method is executed. The model is saved only after the pre_save signal completes successfully.

This signal ensures actions are executed conditionally, for example, only if a specific field has changed.

Using connect() Method

Signals can also be connected without decorators by using the connect() method. This is an alternative to the @receiver decorator.

This method provides the same functionality as receiver decorators, allowing explicit control over which functions handle which signals.

Advantages and Considerations

Signals promote loose coupling by notifying external handlers instead of embedding side effects directly in model methods.