We're using the createBrowserClient function to access the supabase client all across our frontend logic, where hooks are not available to get the client using the useSupabaseClient hook.
We noticed that if we do not pass the exact same options across the clients when we call this function, the existing client-cached options are overridden by other "instantiations." For example, we used the createBrowserClient function in our root app context, and in our auth helper function. In one, we defined common options to override and control, while in the other, we passed no options since we are leveraging the singleton pattern and expect the cached instance to keep the options.
The options we are changing specifically are:
{
auth: {
storage: {}
},
cookies: {}
}
This is causing issues where we are indeed using the same client but with reconfigured options since the function is not correctly merging the user-defined options with the default options. This is causing all sorts of havoc in the app due to inconsistent client behavior.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
Create a browser client using the createBrowserClient and pass it specific client options (like custom get/set cookies)
In another page or function, call the createBrowserClient with no options to get a second client
Call the page/function where the second client is used; check the singleton client options, and they will not be the same.
Expected behavior
In theory, since we are using singleton = true by default and are not modifying it, we get the same instance. And we do, but the options have defaulted back since the second createBrowserClient call had no options, and it internally wrote over the original options.
Screenshots
If applicable, add screenshots to help explain your problem.
bombillazo
commented
3 months ago
Bug report
Describe the bug
We're using the
createBrowserClientfunction to access the supabase client all across our frontend logic, where hooks are not available to get the client using theuseSupabaseClienthook.We noticed that if we do not pass the exact same options across the clients when we call this function, the existing client-cached options are overridden by other "instantiations." For example, we used the
createBrowserClientfunction in our root app context, and in our auth helper function. In one, we defined common options to override and control, while in the other, we passed no options since we are leveraging thesingletonpattern and expect the cached instance to keep the options.The options we are changing specifically are:
This is causing issues where we are indeed using the same client but with reconfigured options since the function is not correctly merging the user-defined options with the default options. This is causing all sorts of havoc in the app due to inconsistent client behavior.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
createBrowserClientand pass it specific client options (like custom get/set cookies)createBrowserClientwith no options to get a second clientExpected behavior
In theory, since we are using singleton = true by default and are not modifying it, we get the same instance. And we do, but the options have defaulted back since the second
createBrowserClientcall had no options, and it internally wrote over the original options.Screenshots
If applicable, add screenshots to help explain your problem.
System information
Additional context
Add any other context about the problem here.