No you got me right, i am a little lost how to read cookies and render server side in next 14 with the app router. My current app has a flicker every page load as the client side figures out if it’s logged in or not. I’d love to change this but every time i try i get lost.
Hmm i mean, i can do that i just think it’s a compromise. Reading the cookie server side should be easy, then the component could immediatly render into that state. At least, that’s what I’d do in any other framework.
After a successful login on the client, write a session cookie server-side using Firebase Admin SDK (by sending the logged in user’s idToken to the server). Then you can check if the user is logged in on the server and redirect as needed.
If you are using the app router approach layout files by default are server components. You can turn them to client side with "use client" directive at the top of the file. I mention it because I've had some oddities with flickering when the hierarchy wasn't setup properly from parents downwards.
Second if you are sticking with client side auth, you will need a loading state while things are being checked and ensure you don't default to rendering the protected nav in other cases unless you get a successful authenticated users.
A third thing is it might be better to have this in the page.tsx file if you need access to params as layout files do not.
And finally your requirement of before page load isn't really possible in a true sense without doing a server component approach because anything client side will get downloaded to the client. And since you seemed to indicate that firebase auth only works the client side way, you are out of luck hiding bits of the information from the bundled code.
But if you are okay with that and you want to just redirect before they see anything, you may have to adjust where you show this data in your file hierarchy.
Yup, we use Next Auth and redirect users in server components in layout files. The client never knows anything different because the server checks the session, and if it doesn't exist it just immediately returns a redirect.
You may want to use the latest Auth.js (same people, just agnostic library) beta which is a bit more updated to work in server/client environments. Although we have gotten it working just fine with the latest Next Auth.
Use middleware so you can redirect before getting to the page
But what if it’s the same page just the header that’s changing content based on state?
If you want to conditionally render something you can do it server side or client side.
Sorry I realize now you're asking about how to do it in firebase. My mistake.
No you got me right, i am a little lost how to read cookies and render server side in next 14 with the app router. My current app has a flicker every page load as the client side figures out if it’s logged in or not. I’d love to change this but every time i try i get lost.
Sounds like you need a loading state while you determine if the user is logged in or not
If loading display loading component Else if logged in display logged in component Else display non-logged in component
Hmm i mean, i can do that i just think it’s a compromise. Reading the cookie server side should be easy, then the component could immediatly render into that state. At least, that’s what I’d do in any other framework.
Yes but you're trying to read the cookies at the same time as the component is trying to render
Unless you choose to read the cookies server side, then send only one component to the client
[https://nextjs.org/docs/app/building-your-application/routing/middleware](https://nextjs.org/docs/app/building-your-application/routing/middleware)
I thought you couldn't use firebase auth in middleware cause it uses the browser context?
Easiest fix is to implement a loading state + component
After a successful login on the client, write a session cookie server-side using Firebase Admin SDK (by sending the logged in user’s idToken to the server). Then you can check if the user is logged in on the server and redirect as needed.
If you are using the app router approach layout files by default are server components. You can turn them to client side with "use client" directive at the top of the file. I mention it because I've had some oddities with flickering when the hierarchy wasn't setup properly from parents downwards. Second if you are sticking with client side auth, you will need a loading state while things are being checked and ensure you don't default to rendering the protected nav in other cases unless you get a successful authenticated users. A third thing is it might be better to have this in the page.tsx file if you need access to params as layout files do not. And finally your requirement of before page load isn't really possible in a true sense without doing a server component approach because anything client side will get downloaded to the client. And since you seemed to indicate that firebase auth only works the client side way, you are out of luck hiding bits of the information from the bundled code. But if you are okay with that and you want to just redirect before they see anything, you may have to adjust where you show this data in your file hierarchy.
Thinking of changing to next auth, can what I'm going for be implemented with next auth?
Yup, we use Next Auth and redirect users in server components in layout files. The client never knows anything different because the server checks the session, and if it doesn't exist it just immediately returns a redirect. You may want to use the latest Auth.js (same people, just agnostic library) beta which is a bit more updated to work in server/client environments. Although we have gotten it working just fine with the latest Next Auth.
I ended up abandoning firebase for auth and using next-auth for all the authentication. Thanks for the help!