I've noticed the issue because I am using both SupaEmailAuth and SupaSocialsAuth. Social auth subscribes to the auth changes directly and calls the onSuccess method when we are logged in, while the email auth uses async - await for log in and then calls the given callback. What happens when I have both is that when logging in via email, first the email callback is called, and then the social onSuccess callback is called as well, because the listener is active. Magic auth would also subscribe to the change, so that would make 2 subscriptions and one async-await when using all three on one page.
One could argue that I should only implement the social login callback and ignore the email callback, but that would simply be a workaround. Also, I use flavors in which some apps have social auth and some not, and it would not be pretty to modify the listeners depending on the current flavor.
I propose a change where we can decide to not subscribe to auth changes and instead handle the login or signup ourselves.
Another option would be to wrap our login page with another widget that holds the auth listener and provides some callbacks for the auth events.
domhel
commented
4 months ago
Chore
Describe the chore
I've noticed the issue because I am using both
SupaEmailAuthandSupaSocialsAuth. Social auth subscribes to the auth changes directly and calls theonSuccessmethod when we are logged in, while the email auth uses async - await for log in and then calls the given callback. What happens when I have both is that when logging in via email, first the email callback is called, and then the social onSuccess callback is called as well, because the listener is active. Magic auth would also subscribe to the change, so that would make 2 subscriptions and one async-await when using all three on one page.One could argue that I should only implement the social login callback and ignore the email callback, but that would simply be a workaround. Also, I use flavors in which some apps have social auth and some not, and it would not be pretty to modify the listeners depending on the current flavor.
I propose a change where we can decide to not subscribe to auth changes and instead handle the login or signup ourselves. Another option would be to wrap our login page with another widget that holds the auth listener and provides some callbacks for the auth events.