Server components and conditional rendering
Unanswered
Argentine ant posted this in #help-forum
Argentine antOP
Hi, just wanted to check...
If you have an auth check in a page for example, and this conditionally renders out server components that should only be seen if you have the correct auth (managed in the page), do I need to do anymore inside of the server component to verify or is it safe to assume the layout has taken care of only showing that component if the auth checks out?
Thanks!
If you have an auth check in a page for example, and this conditionally renders out server components that should only be seen if you have the correct auth (managed in the page), do I need to do anymore inside of the server component to verify or is it safe to assume the layout has taken care of only showing that component if the auth checks out?
Thanks!
25 Replies
@Argentine ant Hi, just wanted to check...
If you have an auth check in a page for example, and this conditionally renders out server components that should only be seen if you have the correct auth (managed in the page), do I need to do anymore inside of the server component to verify or is it safe to assume the layout has taken care of only showing that component if the auth checks out?
Thanks!
No you dont given that the conditions are in the same page.
If you check auth in layout, then yes you would then need to check it again in page.js
If you check auth in layout, then yes you would then need to check it again in page.js
@Alfonsus Ardani No you dont given that the conditions are in the same page.
If you check auth in layout, then yes you would then need to check it again in page.js
Argentine antOP
yeah i assumed so, as long as you don't import the component and render it anywhere without that check higher up
wait so what would be the difference between doing the check in a layout vs the page directly?
@Argentine ant yeah i assumed so, as long as you don't import the component and render it anywhere without that check higher up
you can ensure that by defining the correct props.
component A that needs auth -> Required<Session>
then set the return type of your getSession() -> Session | null
then you can only pass session to component A if you write
component A that needs auth -> Required<Session>
then set the return type of your getSession() -> Session | null
then you can only pass session to component A if you write
if(!session) notFound() / throw new Error('')@Argentine ant wait so what would be the difference between doing the check in a layout vs the page directly?
layouts aren't re-run/re-rendered on soft navigation.
if you navigate from /dash/a to /dash/b,
the layout in /dash/layout,tsx wont get rerun and this leads to stale values
not to mention you can directly fetch the RSC content of /dash/b/page.tsx via postman if you dont put auth check in /dash/b
if you navigate from /dash/a to /dash/b,
the layout in /dash/layout,tsx wont get rerun and this leads to stale values
not to mention you can directly fetch the RSC content of /dash/b/page.tsx via postman if you dont put auth check in /dash/b
Argentine antOP
oh yeah i see... okay thanks for that, i didn't think about that
@Alfonsus Ardani layouts aren't re-run/re-rendered on soft navigation.
if you navigate from /dash/a to /dash/b,
the layout in /dash/layout,tsx wont get rerun and this leads to stale values
not to mention you can directly fetch the RSC content of /dash/b/page.tsx via postman if you dont put auth check in /dash/b
Argentine antOP
is this true even when using cookies inside of a layout?
so only put stuff in layout if its just a non-critical values or cosmetic stuff
Argentine antOP
oh actually I just checked, i probably thought about that previously. I have a seperate
layout component that isn't strictly a next.js layout, just another RSC that acts as onewhen i say
layout i meant layout.tsx. Any RSC that goes in there will go staleArgentine antOP
oh i see, so pretty much have to do it at the page level regardless
yeah you should be good if you have your "layout" component in page.js that handles auth stuff
basically an auth wrapper
// page.js
<Protected>
....
</Protected>
<Protected>
....
</Protected>
@Alfonsus Ardani when i say `layout` i meant `layout.tsx`. Any RSC that goes in there will go stale
Argentine antOP
what's quite weird is on one of my projects i have a sidebar component directly in
layout.tsx that handles auth to render out stuff, when the cookie changes it re-renders - would you say this is expected behaviour? or is it just an issue of soft navigationhow did you change the cookies? via client or via an api route/server acton?
@Alfonsus Ardani No you dont given that the conditions are in the same page.
If you check auth in layout, then yes you would then need to check it again in page.js
Chub mackerel
conditional render in server component will cuased on hydration error?
@Alfonsus Ardani how did you change the cookies? via client or via an api route/server acton?
Argentine antOP
used a server action and also coupled with router.refresh so was a hard refresh
yeah makes sense actually
its a hard refresh therefore it will re-run layouts
yeah
Argentine antOP
soft navigation still the issue 😂 thanks though! probably bad practice to have that stuff in layout anyways. So just to confirm, I have my auth wrapper component, I can import my components that don’t do any other checks on their own since they’re conditionally rendered by the wrapper
@Alfonsus Ardani you can ensure that by defining the correct props.
component A that needs auth -> Required<Session>
then set the return type of your getSession() -> Session | null
then you can only pass session to component A if you write
tsx
if(!session) notFound() / throw new Error('')
mmmmmm generally you could just do this and prevent using any react component as a RSC wrapper just for extra security