steve-marmalade
commented
9 months ago Hi @rgbskills , I also found my app getting into an inconsistent state like this, and figured I'd share my experience (and curious what the great and powerful @awinogrodzki things of my approach).
Instead of storing the user in client-side state, which gets set via an onIdTokenChanged event listener, I've deviated from the examples in this repo to make the client side be purely a function of the server state.
So the flow is:
- A single client component is mounted in my root layout, which sets up the
onIdTokenChangedlistener. The handler simply calls/api/loginwith the updated token. - Wherever I need access to user data in a client component in my application, I wrap that component in a ServerAuthProvider, and pass in the user to the client context via cookies. The client side auth context has no way to update this value. It just takes the user info from cookies and makes it available to child client components.
This setup guarantees consistency between server and client components, is simple to reason about (since there's a single source of truth for the data and it only flows one way), and I think this approach is well suited to future NextJS enhancements like Partial Pre-Rendering, since the user-specific components on a page will be wrapped in Suspense and triggered once cookies are accessed.
awinogrodzki
I'm encountering issues with my application's user interface becoming inconsistent under certain conditions. Specifically, these issues arise when users either manually delete the 'AuthToken' cookie or when the client-side logout process fails, even though the server-side logout is successful. As a result of this, the navigation bar incorrectly displays the user as logged in, while server-side middleware redirects the user to the login page due to its own authentication checks.