Taming the Loading Spinner Beast during User Sign-In

TL;DR

• Mismanagement in state propagation can make loaders linger indefinitely.
• Debugging by logging current states is essential to trace how each step in code execution modifies global state variables.
• Handling errors explicitly and pruning unnecessary state checks helps clean up logic and solve bugs.

Implementing a persistent loading spinner during the user sign-up/sign-in process turned out more nuanced than I initially anticipated. At the outset, it appeared straightforward—keep critical context providers like AuthContext and AppDataContext visible during these triggers. However, the interplay between different states presented unique challenges.

I centered my approach around the AppDataContext, responsible for a loading overlay, with state flags such as isLoading, isSigningUp, and isSigningIn. My first hypothesis was flawed: the spinner stayed hidden except under specific conditions. The oversight likely lay in the way I was initializing component states.

Initial Steps:

1. Contextual Setup: Wrapping the app via AppDataContext equipped to handle isLoading and potential isSigningIn or isSigningUp states.
2. Negating Initialization States: Tweaked logic to avoid the spinner when the overall app or user data is initializing. This was nailed by adding a conditional check that wasn’t needed due to the splash screen.

Noting persistent issues with spinners not disappearing even upon completion, I deployed strategic console logging. This identified the root: Boolean logic was incorrectly encompassing states, unintentionally persisting the spinner.

Debugging & Refactoring:

• Simplifying State Checks: Reducing multiple states to an isolated isSigningIn/isSigningUp. Removing the refreshing and unnecessary isLoading flags was crucial.
• Error Handling: Ensured try-catch logic wouldn’t blanket skip state resets. I realized the explicit wrap of Auth0 function led to exceptions not resetting the state, causing stale flags.

Conclusion:

This journey underlines the importance of consolidating complex state management into simplified, well-named pieces that accurately represent their function at a high level. Excessive conditionals obscured logic flow, as was evident in unexpected behavior on cancel or error paths. Ultimately, moving towards clearer state intentions facilitated the desired functionality—ensuring the loading screen’s presence only during true need, and absent otherwise.