Auth state change listeners in Supabase - Time & Space Complexity
When using auth state change listeners, it is important to understand how the number of listeners affects performance.
We want to know how the work grows as more listeners are added or triggered.
Analyze the time complexity of setting up and triggering auth state change listeners.
const { data: authListener } = supabase.auth.onAuthStateChange((event, session) => {
console.log('Auth event:', event);
// handle session update
});
// Later, when auth state changes, all listeners are called
// For example, user signs in or out
This code sets up a listener that runs a callback whenever the authentication state changes.
Look at what happens repeatedly when auth state changes.
- Primary operation: Calling each registered auth state change listener callback.
- How many times: Once per listener for every auth state change event.
As the number of listeners increases, the number of callback calls grows directly with it.
| Number of Listeners (n) | Approx. Callback Calls per Event |
|---|---|
| 10 | 10 |
| 100 | 100 |
| 1000 | 1000 |
Pattern observation: Each auth event triggers all listeners, so the work grows linearly with the number of listeners.
Time Complexity: O(n)
This means the time to handle an auth state change grows directly with the number of listeners registered.
[X] Wrong: "Adding more listeners won't affect performance because they run independently."
[OK] Correct: Each listener callback runs one after another on every auth event, so more listeners mean more work and longer handling time.
Understanding how event listeners scale helps you design responsive apps and manage resources well, a key skill in cloud and frontend development.
What if we batch multiple auth events before notifying listeners? How would that change the time complexity?
Practice
Solution
Step 1: Understand auth state change listener role
An auth state change listener watches for user login or logout events.Step 2: Identify its main use in app behavior
It updates the app UI or logic based on whether the user is signed in or out.Final Answer:
To detect when a user logs in or logs out and update the app accordingly -> Option CQuick Check:
Auth listener updates app on login/logout [OK]
- Thinking it sends emails automatically
- Confusing with data storage functions
- Assuming it encrypts passwords
Solution
Step 1: Recall Supabase auth listener method
The correct method to listen for auth changes isonAuthStateChange.Step 2: Verify method signature
It takes a callback with parameterseventandsession.Final Answer:
supabase.auth.onAuthStateChange((event, session) => { /* handler */ }) -> Option BQuick Check:
Use onAuthStateChange for auth listeners [OK]
- Using non-existent methods like listenAuthChange
- Confusing subscribe or watchStateChange methods
- Incorrect callback parameters
const { data: authListener } = supabase.auth.onAuthStateChange((event, session) => {
console.log(event);
});
// User signs out here
supabase.auth.signOut();Solution
Step 1: Understand event on user sign out
When a user signs out, the event emitted is "SIGNED_OUT".Step 2: Check console.log output
The listener logs the event string, so it will print "SIGNED_OUT".Final Answer:
"SIGNED_OUT" -> Option AQuick Check:
Sign out triggers SIGNED_OUT event [OK]
- Expecting SIGNED_IN on sign out
- Thinking USER_UPDATED triggers on sign out
- Assuming no event is logged
const authListener = supabase.auth.onAuthStateChange((event, session) => {
if(event === 'SIGNED_IN') {
console.log('User signed in');
}
});
// Later in code
authListener.unsubscribe();Solution
Step 1: Check how onAuthStateChange returns subscription
It returns an object with adataproperty containing the subscription.Step 2: Verify unsubscribe method call
Unsubscribe should be called onauthListener.data.subscription.unsubscribe(), not directly onauthListener.unsubscribe().Final Answer:
authListener.unsubscribe() is incorrect; should use authListener.data.subscription.unsubscribe() -> Option AQuick Check:
Unsubscribe via authListener.data.subscription.unsubscribe() [OK]
- Calling unsubscribe directly on listener object
- Misnaming event strings
- Skipping unsubscribe causing memory leaks
Solution
Step 1: Identify events to trigger UI update
Only 'SIGNED_IN' and 'SIGNED_OUT' events should update the UI.Step 2: Check conditional logic in each option
supabase.auth.onAuthStateChange((event, session) => { if(event === 'SIGNED_IN' || event === 'SIGNED_OUT') { updateUI(session); } }); correctly checks for these two events and callsupdateUIaccordingly.Final Answer:
supabase.auth.onAuthStateChange((event, session) => { if(event === 'SIGNED_IN' || event === 'SIGNED_OUT') { updateUI(session); } }); -> Option DQuick Check:
Update UI only on SIGNED_IN or SIGNED_OUT [OK]
- Updating UI on all events without filtering
- Using wrong event names like USER_UPDATED
- Negating conditions incorrectly
Ready to prove it?
Pass the test and this pattern moves unknown
