Jump into concepts and practice - no test required
or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Using Custom Signals in Django
📖 Scenario: You are building a Django app that needs to perform an action whenever a new user profile is created. Instead of putting this logic directly in the view or model, you will use a custom signal to keep your code clean and organized.
🎯 Goal: Create a custom Django signal called profile_created that triggers when a new user profile is saved. Connect a receiver function to this signal that prints a message confirming the profile creation.
📋 What You'll Learn
Create a custom signal named profile_created
Define a receiver function called profile_created_receiver
Connect the receiver to the profile_created signal
Send the profile_created signal after saving a new profile
💡 Why This Matters
🌍 Real World
Custom signals help keep Django apps organized by separating event handling logic from models and views. This is useful in large projects where multiple actions need to happen after certain events.
💼 Career
Understanding custom signals is important for Django developers to write clean, maintainable code and to implement event-driven features in web applications.
Progress0 / 4 steps
1
Create the custom signal
In a file called signals.py, import Signal from django.dispatch and create a custom signal named profile_created.
Django
Hint
Use Signal() to create a new signal object.
2
Define the receiver function
In signals.py, define a function called profile_created_receiver that accepts sender and **kwargs parameters. Inside the function, write a comment saying # This function will handle the signal.
Django
Hint
The receiver function must accept sender and **kwargs.
3
Connect the receiver to the signal
Still in signals.py, connect the profile_created_receiver function to the profile_created signal using the connect method.
Django
Hint
Use profile_created.connect(profile_created_receiver) to link the receiver.
4
Send the signal after saving a profile
In your models.py, after saving a new profile instance, import profile_created from signals and send the signal using profile_created.send(sender=Profile, instance=profile) where profile is the saved instance.
Django
Hint
Override the save method in the Profile model to send the signal after saving.
Practice
(1/5)
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
Step 1: Understand what custom signals do
Custom signals let different parts of a Django app send messages to each other without direct links.
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.
Final Answer:
To allow different parts of an app to communicate without being tightly connected -> Option D
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
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.
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.
Final Answer:
my_signal = Signal(providing_args=["instance", "created"]) -> Option B
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?
The signal is sent with instance='obj1' and created=True. The receiver prints these values from kwargs.
Step 2: Match printed output to sent values
The print statement uses kwargs['instance'] and kwargs['created'], so it prints 'obj1' and 'True'.
Final Answer:
Received: obj1, Created: True -> Option A
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
Step 1: Check receiver function signature
Receivers must accept sender and **kwargs to handle all signal arguments flexibly.
Step 2: Identify mismatch in receiver parameters
The receiver only accepts sender and data, missing **kwargs, which causes errors when extra arguments are sent.
Final Answer:
The receiver function must accept **kwargs, not just named arguments -> Option A
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
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.
Step 2: Send signal with matching arguments
When sending, include both user and major_update to match the signal definition and receiver expectations.
Final Answer:
Define signal with providing_args=['user', 'major_update'] and send with user=user_obj, major_update=True -> Option C
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