Reputation: 1784
Update: Due to code refactor, the need for testing that has gone away, and as Ron pointed out in the accepted answer, onAuthStateChange()
will fire eventually, and the app can rely on that. I wasn't originally seeing that, which is what motivated my question.
Original Question: I've been using window.localStorage
and searching for a key that starts with 'firebase:authUser'
as a way to determine if my app can expect a firebase authentication event any time soon. Whether it succeeds or fails, firebase.auth().onAuthStateChanged()
is triggered, and I can deal with the result there. The reason for wanting to know is that if I have some local credentials which are being processed, my app can display a 'Please wait...' type message. But if there are none, it can redirect immediately to the login page. Since firebase moved to indexedDB
, this code no longer works, and I couldn't find any equivalent hack to look for locally persisted credentials (maybe it's not possible now?).
I'd also be happy to switch to SESSION
persistence rather than LOCAL
, but I'm not sure if this changes the scenario at all—I'd still need a way to test if there was anything happening to avoid the user being stuck at the 'Please wait...' message forever if there were no local credentials to validate.
Or am I doing this wrong? I know I could show the login page until firebase.auth().onAuthStateChanged()
fires, but by then the user might have clicked, and the experience isn't that great either if they already signed in and then refresh the page, where they see the login page again until everything is loaded.
I couldn't find anything in the auth()
API to tell if it was in the process of dealing with locally persisted credentials, and up until now, the window.localStorage
hack has been working very well. What's the best way to manage the user experience now?
Upvotes: 1
Views: 1467
Reputation: 30798
Relying on underlying implementation is never a good idea instead of provided public API. Firebase has the right to change that at any time. They could have even persisted the user with a different format and that would break your implementation.
That said, you can easily bypass this, by setting your own flag in localStorage
when a user logs in and remove it when they sign out. This is better than relying on the hack you had. In this case, you have full control over that flag. You set it anytime a user is signed in after onAuthStateChanged
is triggered and remove it on sign out. When a page is loaded you read that value directly to know whether to display the progress bar or not.
Upvotes: 1
Reputation: 18555
You could grey out inputs and disable submit button until .onAuthStateChanged
resolves which happens very quickly, usually in under 1 second. Maybe put a linear progress indicator on the login form?
Upvotes: 1