Next.js Discord

Discord Forum

Mixing server-side and client-side sections in Next.js

Unanswered
Florian posted this in #help-forum
Open in Discord
FlorianOP
How much do you mix server-side and client-side sections in Next.js?

Here is an example profile page I'm building.

The red part is server-side fetched and rendered and the orange part client-side (because it's an infinite loading list).

But this requires me to retrieve the current user session twice.

I need it in the profile section to show whether I am following this user. I also need the session in the feed below for the liked state.

Do you mix SSR and CSR like this, fetching sessions on both sides when necessary? Or is this a bad design?

40 Replies

@B33fb0n3 yea, the mixing is sometimes fine. You can put it inside a react cache to fetch your datasource only once per request
FlorianOP
You mean the SSRed part, right? But that's only necessary if I need that data in multiple places on that page. Which I actually do, because I also use it to set the Metadata.
And I have the SSR part wrapped into React#cache. But the CSR part is loaded afterwards via React-Query.
@Florian You mean the SSRed part, right? But that's only necessary if I need that data in multiple places on that page. Which I actually do, because I also use it to set the Metadata.
B33fb0n3
Good, you can still cache it and revalidate it every 5 seconds or something like that. Than you have cache (serverside: data cache) and you client and your server will get the same data within these 5 seconds
@B33fb0n3 Good, you can still cache it and revalidate it every 5 seconds or something like that. Than you have cache (serverside: data cache) and you client and your server will get the same data within these 5 seconds
FlorianOP
I'm not sure what you're referring to. The red part is SSRed. The orange part is fetched client-side. There is no connection between the two and they don't revalidate after 5 seconds.
What I'm concerned about is mixing SSR and client-side fetching like this (because I fetch the user session twice for one page).
B33fb0n3
I am talking about the fetching part. Fetching clientside and fetching serverside. From somewhere the data comes from (data source) and this data source is normally handled serverside. And when it’s serverside, you can use the data cache. And when you can use data cache, you can also revalidate them in specific timings (time based revalidation)
FlorianOP
What do you mean by data cache? I think sessions are not cached, they are always fetched fresh.
@Florian What do you mean by data cache? I think sessions are not cached, they are always fetched fresh.
B33fb0n3
Of course sessions should not be cached and should always be fresh. On the other hand you don't want to fetch is over and over again just to get the data
@Florian Yea that's what I'm trying to figure out
B33fb0n3
so my solution would be, to revalidate the cache every 5 seconds (automatically & time based): https://nextjs-forum.com/post/1255793919418044487#message-1255805258987208766
James4u
I think this unfollow button should be client component
so while rendering red part, you don't need to fetch user session on the server side. just leave the unfollow button as a whole.
maybe you can put skeleton there while you load user session on the client-end, once you finish loading user session, you can show "follow" or "unfollow"
@James4u I think this unfollow button should be client component
B33fb0n3
Yes, a button with an onClick event need to be clientside. You can create a Component called „FollowButton“ it takes children as children inside the button. Then the full functionality is inside this client component (button), but the rendering (fetching part) is serverside. Like that, you can directly use either the data cache or react cache to have it caches per request
riský
you could also make a form and make the submit button - and all server
@B33fb0n3 I am talking about the data cache: https://nextjs.org/docs/app/building-your-application/caching#data-cache
FlorianOP
So you're suggesting that I wrap the session retrieval in unstable_cache (which is how you get non-fetch calls into the data cache)? If not, can you be more specific?
@James4u so while rendering red part, you don't need to fetch user session on the server side. just leave the unfollow button as a whole.
FlorianOP
The follow button is a client component but I don't want a loading state for it. That would also not solve the problem because I still need the session twice.
@riský *you could also make a form and make the submit button - and all server*
FlorianOP
The feed needs to be client-side, there is no way around that.
@Florian The feed needs to be client-side, there is no way around that.
B33fb0n3
I guess he talked about the follow/unfollow button
@B33fb0n3 ohhh that's smart as well 😮
riský
id still have some client for spinner nested within (useFormStatus), so not all client anyway
@Florian So you're suggesting that I wrap the session retrieval in unstable_cache (which is how you get non-fetch calls into the data cache)? If not, can you be more specific?
B33fb0n3
@riský do you know if the react cache would handle the dedupe when it's used clientside and serverside but within the same request? 🤔
riský
im confused
how would react/next know how to share the state without being a massive sec issue of sharing the cache with client (ie many could put some things like api keys that client shouldnt see)
@riský id still have some client for spinner nested within (useFormStatus), so not all client anyway
B33fb0n3
yea, I would directly use next-safe-action. They have the server actions stuff and the status stuff. With that I would get a spinner and can have a "LoadingButton" component, that handles everything. But that's just my setup. I don't know what's Florians setup
FlorianOP
I don't think wrapping session retrieval into unstable_cache is a good idea. I want a fresh session.
The answer is probably that I should pass initial data from the server component to React-Query
i.e. the first page
but that overcomplicates things so I'll probably just accept fetching the session twice
@Florian but that overcomplicates things so I'll probably just accept fetching the session twice
B33fb0n3
Most of the time it's not needed to fetch the user session clientside. I guess there are also a ways to do things here serverside, so you don't need to fetch mutiple times. I don't know enought to give you a clear advice, so just this general advice. All the best for you project 👍
FlorianOP
As I explained, I fetch my feed data client-side into an infinite loading list (you can't do that server-side). So yes, I absolutely need the session client-side.
FlorianOP
Once for the server rendered part (the profile) and once for the feed (fetched via React-Query)
Once server-side, once client-side (and then for every newly fetched page)