Custom signals in Django - Step-by-Step Execution

Concept Flow - Custom signals

Define signal

↓

Connect receiver function

↓

Trigger signal.send()

↓

Django calls receiver

↓

Receiver executes custom code

↓

Signal handling complete

This flow shows how a custom signal is defined, connected to a receiver, triggered, and handled in Django.

Execution Sample

Django

from django.dispatch import Signal, receiver

# Define signal
my_signal = Signal()

# Connect receiver
def my_receiver(sender, **kwargs):
    print(f"Received: {kwargs['data']}")

my_signal.connect(my_receiver)

# Trigger signal
my_signal.send(sender=None, data="Hello")

This code defines a custom signal, connects a receiver function, and triggers the signal with data.

Execution Table

Step	Action	Evaluation	Result
1	Define my_signal	Signal object created	my_signal ready to use
2	Define my_receiver	Function defined	my_receiver ready
3	Connect my_receiver to my_signal	my_signal.connect(my_receiver)	Receiver registered
4	Call my_signal.send(sender=None, data='Hello')	Signal triggers	my_receiver called
5	Inside my_receiver: print(f"Received: {kwargs['data']}")	Print statement executed	Output: Received: Hello

💡 Signal handling complete after receiver executes

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	Final
my_signal	undefined	Signal object	Signal with receiver connected	Signal triggered	Signal ready for next use
my_receiver	undefined	undefined	Connected to signal	Called by signal	Function execution done

Key Moments - 3 Insights

Why do we connect the receiver function to the signal before sending it?

The receiver must be connected first so Django knows which function to call when the signal is sent, as shown in step 3 and 4 of the execution_table.

What happens if no receiver is connected when the signal is sent?

If no receiver is connected, sending the signal does nothing because no function is called, so no output appears (no step 5 execution).

Why do we pass 'sender' when sending the signal?

The 'sender' identifies who sent the signal; it can be None or any object. Receivers can use it to filter signals, as shown in step 4.

Visual Quiz - 3 Questions

Look at the execution_table, what is printed at step 5?

A Received: Hello

B Hello

C Signal sent

D No output

💡 Hint

Check the 'Result' column in step 5 of the execution_table.

At which step is the receiver function connected to the signal?

A Step 1

B Step 3

C Step 4

D Step 5

💡 Hint

Look for the action 'Connect my_receiver to my_signal' in the execution_table.

If we do not call my_signal.send(), what happens?

A Receiver is called anyway

B Signal is connected twice

C Receiver is never called

D Error occurs

💡 Hint

Refer to key_moments about what happens if no signal is sent.

Concept Snapshot

Custom signals in Django:
- Define with Signal()
- Connect receiver with signal.connect(func)
- Send signal with signal.send(sender, **kwargs)
- Receiver runs when signal sent
- Use for decoupled event handling

Full Transcript

This visual execution shows how to create and use custom signals in Django. First, a signal object is defined. Then, a receiver function is created and connected to the signal. When the signal is sent with data, Django calls the receiver function, which executes custom code such as printing a message. The variable tracker shows the signal and receiver states at each step. Key moments clarify why connection must happen before sending and what happens if no receiver is connected. The quiz tests understanding of the printed output, connection step, and behavior when the signal is not sent.

Practice

1. What is the main purpose of custom signals in Django?

easy

A. To create new database tables dynamically

B. To speed up database queries automatically

C. To replace Django's URL routing system

D. To allow different parts of an app to communicate without being tightly connected

Solution

1. Step 1: Understand what custom signals do

   Custom signals let different parts of a Django app send messages to each other without direct links.

2. Step 2: Compare options to this purpose

   Only To allow different parts of an app to communicate without being tightly connected describes this communication purpose; others describe unrelated features.

3. Final Answer:

   To allow different parts of an app to communicate without being tightly connected -> Option D

4. Quick Check:

   Custom signals = loose communication [OK]

Hint: Custom signals help parts talk without tight links [OK]

Common Mistakes:

• Thinking signals speed up queries
• Confusing signals with URL routing
• Believing signals create database tables

2. Which of the following is the correct way to define a custom signal in Django?

easy

A. my_signal = signal(["instance", "created"])

B. my_signal = Signal(providing_args=["instance", "created"])

C. my_signal = Signal(args=["instance", "created"])

D. my_signal = Signal(provides=["instance", "created"])

Solution

1. Step 1: Recall Django's Signal class syntax

   The correct way is to create a Signal object with providing_args as a list of argument names.

2. Step 2: Check each option's syntax

   Only my_signal = Signal(providing_args=["instance", "created"]) uses Signal with providing_args correctly; others use wrong parameter names or lowercase Signal.

3. Final Answer:

   my_signal = Signal(providing_args=["instance", "created"]) -> Option B

4. Quick Check:

   Signal(providing_args=...) is correct syntax [OK]

Hint: Use Signal(providing_args=[...]) to define custom signals [OK]

Common Mistakes:

• Using lowercase 'signal' instead of 'Signal'
• Using 'args' or 'provides' instead of 'providing_args'
• Passing arguments without a list

3. Given this code snippet, what will be printed when my_signal.send(sender=None, instance='obj1', created=True) is called?

from django.dispatch import Signal, receiver

my_signal = Signal(providing_args=["instance", "created"])

@receiver(my_signal)
def my_receiver(sender, **kwargs):
    print(f"Received: {kwargs['instance']}, Created: {kwargs['created']}")

medium

A. Received: obj1, Created: True

B. Received: None, Created: True

C. Received: obj1, Created: False

D. Error: missing sender argument

Solution

1. Step 1: Understand signal sending and receiver

   The signal is sent with instance='obj1' and created=True. The receiver prints these values from kwargs.

2. Step 2: Match printed output to sent values

   The print statement uses kwargs['instance'] and kwargs['created'], so it prints 'obj1' and 'True'.

3. Final Answer:

   Received: obj1, Created: True -> Option A

4. Quick Check:

   Signal send values print correctly [OK]

Hint: Receiver prints kwargs values sent by signal [OK]

Common Mistakes:

• Confusing sender with instance
• Assuming created is False by default
• Thinking sender is required in print

4. What is wrong with this code that tries to connect a receiver to a custom signal?

from django.dispatch import Signal

my_signal = Signal(providing_args=["data"])

def receiver_func(sender, data):
    print(f"Data: {data}")

my_signal.connect(receiver_func)

medium

A. The receiver function must accept **kwargs, not just named arguments

B. Signal must be imported from django.signals, not django.dispatch

C. The connect method requires a sender argument

D. providing_args should be a tuple, not a list

Solution

1. Step 1: Check receiver function signature

   Receivers must accept sender and **kwargs to handle all signal arguments flexibly.

2. Step 2: Identify mismatch in receiver parameters

   The receiver only accepts sender and data, missing **kwargs, which causes errors when extra arguments are sent.

3. Final Answer:

   The receiver function must accept **kwargs, not just named arguments -> Option A

4. Quick Check:

   Receiver needs **kwargs for signal args [OK]

Hint: Receiver functions always need **kwargs parameter [OK]

Common Mistakes:

• Forgetting **kwargs in receiver signature
• Importing Signal from wrong module
• Assuming connect requires sender argument
• Confusing list and tuple for providing_args

5. You want to create a custom signal that notifies when a user profile is updated, sending the user instance and a flag if the update was major. Which of these is the best way to define and send this signal?

hard

A. Define signal with no providing_args and send with user=user_obj, major_update=True

B. Define signal with providing_args=['user'] and send with user=user_obj, major_update=True

C. Define signal with providing_args=['user', 'major_update'] and send with user=user_obj, major_update=True

D. Define signal with providing_args=['user', 'major_update'] but send only user=user_obj

Solution

1. Step 1: Define signal with all expected arguments

   Since you want to send both user and major_update, both must be listed in providing_args.

2. Step 2: Send signal with matching arguments

   When sending, include both user and major_update to match the signal definition and receiver expectations.

3. Final Answer:

   Define signal with providing_args=['user', 'major_update'] and send with user=user_obj, major_update=True -> Option C

4. Quick Check:

   Signal args must match send args [OK]

Hint: Match providing_args and send arguments exactly [OK]

Common Mistakes:

• Omitting arguments in providing_args
• Sending arguments not declared in providing_args
• Defining signal without providing_args but sending args