SSR with NextJS's App Router

[jvenki]

I already have React Client Components coded with lots of useState and useRef. If I use Pages Router architecture of NextJS, I am able to render this on the server side (SSR) perfectly. But I want to use the new App Router architecture as thats the latest direction of NextJS company. But App Router architecture uses React Server Components by default (RSC) and RSC has lot of restrictions around the usages of useState and useRef for good reasons. But it defeats the purpose of using the existing code to get SSR using NextJS. I dont want to mark those as "use client" as I want them to be server rendered for SEO purposes.

In my particular case, fetching data from server is a simple thing and thus RSC is not solving a lot for me there. But the HTML is interactive a lot and thus useState and useRef are used heavily.

I am wondering whether I am wrong in my understanding of latest App Router architecture where it forces RSC and thus the existing code has to be rewritten properly to make them Server Side Rendered? Or there is a way I can get SSR working on the old client components without changing them a lot and hydration enables interactivity on those components on the browser side.

[makibat]

Both server components and client components first render on the server, and the HTML gets sent to the client, as you can see here.

Next.js will use React's APIs to render a static HTML preview on the server for both Client and Server Components. This means, when the user first visits your application, they will see the content of the page immediately, without having to wait for the client to download, parse, and execute the Client Component JavaScript bundle.

Long story short, by adding "use client" at the very top of your file, you basically enable client side interactivity for that component. The directive itself won't affect SEO.

[jvenki]

Thanks for the reply.

From the snippet in React Docs, I thought Client Components (marked through 'use client' directive) are rendered on the client only.

We introduce the following definitions:

Client Components are components in a render tree that are rendered on the client.
Server Components are components in a render tree that are rendered on the server.

Basis your link to NextJS, NextJS renders client components also on the server which is what I am looking for. I will now go on the journey of marking the boundaries properly with use-client directive to achieve SSR.

[jvenki]

If I use "use client" directive, the server doesnt render the HTML at all. The payload has only Javascript and its the browser which does everthing.

[markoleavy]

If I use "use client" directive, the server doesnt render the HTML at all.

That's incorrect. Both client and server components are rendered as HTML in static pages for performance and SEO purposes, and that html will be fully available on first page load or with js disabled (crawlers).
The difference will be in the hydration process and in the client side navigation: the RSC payload (that replace the old .json file of page routing) will include rendered server components (kind of html tags), and client components props.
During client side navigation client components props will be passed to the javascript and rendered locally, while server components will be served immediately.
Server components js (and imported libraries) won't be loaded on the client, reducing the bundle size and the execution time.

[guiyumin]

During client side navigation client components props will be passed to the javascript and rendered locally

let's say you need to fetch a list of posts, and you use use client directive, what happens then?

i guess the list of posts will be fetch in the browser side, and the google spider will not be able to see the list

correct ?

[markoleavy]

Not if you correctly use SSG. If you fetch the content of the posts client side, they won't be rendered (that would be in any version of any framework as JavaScript is not executed during crawling).
If you pass the props from the server in a client component instead and make sure that SSG is active, your posts will be rendered in the static html and available for the crawlers