does your cms need to like fetch some data initially?

like on page load

ping me

Yes, almost every single page has to load some data

Actually, literally every page loads data 😂

Every route loads data, and there is only 1 route that doesnt load data initially but it has components that loads data

Ok so

Imagine you have a page called test

The page.tsx will be ssr

Fetch your data in it

And then call a client component

And pass your data to it

This client component will be your actual page where you render components

This way you can fetch on the server whilst still being very client based

Okey, yes, that's what im doing now, but what if I want to add some interaction such as deleting from DB, 1 element from the fetched data? I can simply revalidate data i assume, after deletion

Yes, revalidate will work

Make sure to revalidate from a server action

So that you don't need to router.refresh :)

It will directly refetch the data

Hmm, idk what are you talking about, can you explain a bit more in depth? what's server action exactly and how it won't need a router.refresh?

Do you know route handlers?

/api stuff

yeas

Ok so when you revalidate inside it

You need to do router.refresh right?

Didn't try yet that, but I don't think so.. , if im using the new feature with tag revalidation

i might not need a router.refresh

https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations

Read up on this..

With this you won't need to do a router.refresh manually.

If you didn't get what this means.. just use a route handlers with router.refresh.. dosent matter much

https://www.youtube.com/watch?v=xWkozeculPo Can you watch this and let me know what do you think about? 🤔 @Arinji

I swear, in past week, i got so much info about SSR that i feel so overwhelmed

But, at least I feel like building a puzzle, slowly I start putting together pieces and maybe one day I will fully understand how those things works

In 1 sentence, I would like to understand how to do with SSR everything that useSWR does by default 😂 😂 caching, revalidation, fetching and so on, also to understand when to use SSR and when to use Client components. because I still have to figure out, when is "TOO MUCH INTERACTIVITY" for SSR

I’ve been there, that day will surely come sooner than you expect and later you’ll be the one helping instead 😉

One sentence, you can’t do with SSR what useSWR (or react query) does. Both of these client side libraries are designed for client side needs. SSR is just that, “RENDERING” in the server. This means: instead of making your browser fetch data and build the initial HTML you let the Server pull all the data needed, build the HTML and send the full HTML down to the client

This SSR code will run once on the server (obviously) and will run again in the client (this is hydration), basically all the JavaScript that ran on the server will re run on the client to attach events, run effects and attach refs to DOM nodes

Yes, i pretty much understood it, but personally I'm trying to understand the hype around SSR, because I don't find it useful, since almost all CMS websites needs a lot of client interactivity and a lot of real-time data, so how am I even going to make a use of SSR, if I have to constantly fetch data and update data ?

also, for example right now, in my project I need real-time database interaction, like INSTANT RESPONSE to any update to the database ( we are using firebase ), and I can easily do that on client using the onSnapshot from firebase. and Im pretty sure this would be much more efficient than fetching on server and revalidating data every 1 second 😓

That’s better handled by a client side approach.
You can still leverage the server by using Next.js features FROM the client.

Server actions for example, you can call these server functions from your client and these libraries, SWR and react query, work fine as long as they get an async function

The server interaction will remain in the server through server actions being called on the client through these hooks

Let your page render first on the server, add metadata if needed, do whatever server stuff you can or want, even a fetch for initial data, then move the rest to the client

CMS and dashboards do not get much out of server components, most interaction require client side features

so SSR is pretty much good for things that needs to fetch data only and needs LITTLE of interaction such as little bit of filtering/searching or such stuff, and i assume it can go very well with searching engines such as elastic search or meilisearch since those things can be called on server only, and u can tehnically call them right inside a Server component instead of making an api call, a great example that comes in my mind now would be an e-comm website where users pretty much search/add to cart/scroll through fetched data, so not much interaction there

The best approach I've got like some days ago, was tehnically to fetch some initial data on server ( it was a users control page )
and I was fetching on server like 100 users, and use it as fallback data in a SWR then move the entire interaction such as removing users/changing status of the user and everything else to client, mutating data from client if some client interactivity was made

Traditional SSR will only render first on the server do the client gets something on initial load instead of a blank page with an empty <div> that the client will pick up and start rendering from there

Server components are different from SSR, these will only ever execute on the server, which means you can fetch data directly there and then forward that data to client components, this data can be set as the “initial data” for these client side hooks like useSWR y react query useQuery.

SSR is pretty useful when your page needs to be fully rendered before showing to the user, for SEO purposes, for example.

Server components aren’t necessarily SSR, yes, they’re rendered on the server which makes them SSR, but the point of server components is to render once and output a description of the rendered tree of UI, then ship as “static shell with slots” to your website, basically. Also you can dynamically generate these shells on demand, basically forcing react to re-run that component on the server and send back to the client only the payload ( the output it produces)
You can use this to run a fetch on the server