Next.js Discord

Discord Forum

Determining Server or Client Component

Unanswered
Masai Lion posted this in #help-forum
Open in Discord
Masai LionOP
New to Next, damn this is confusing lol. Possibly dumb questions, sorry:

1. Is there a quick way to know whether the component I am looking at will be rendered on the server or client in my editor or in browser?

2. Although layouts and pages default to server, apparently regular components take the form of whatever component imports them. So should I always specify use server in my components to make sure they don't needlessly get client-side-rendered if imported into a client component?

3. In the image example, the yellow client side /app/listing/layout.tsx contains some server side components inside. Is it true that server rendered components get to the user's browser instantly, then the client sided ones are streamed in later? Wouldn't this cause big UI shifts as they come in? If so how do you minimize this?

4. NextUI uses the provider pattern and wants me to wrap my root layout in their provider. I doubt it, but, would that make my entire app CSR?

19 Replies

emacs
I’m new and have been wondering similar things. I’ve written most of my app code to use server components by default and then import any client components. I was looking at NextUI and this pattern wouldn’t work as they want everything rendered client-side for their components but that seems to be the general consensus among other libraries. I’d love to see a best practices doc for how to structure components so that we can take advantage of SSR and also component libraries that need CSR
American Chinchilla
1. Yes and no--depends on the context the component is rendered in.
2. use server is for server actions. My general rule of thumb is to only put the "use client" directive there are state, event handlers, or some other functionality that requires it. I cover a bit in the next point, but components imported won't necessarily by client components--see the ListingItems in the image
3/4. Everything is SSR by default (an initial, static preview will be made on the server before being sent to the client). Passing server components to client components as children does not necessarily make them client components (in the image you posted, the ListingItems are server components). The components don't exactly hit instantly, the server will deliver a bunch of stuff before the data is finished fetching. Impacts to UI can be minimized using Suspense or loading screens
- https://nextjs.org/docs/app/building-your-application/rendering/client-components#how-are-client-components-rendered
- https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming
This is a pretty helpful resource for a lot of the questions you asked as well: https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns
American Chinchilla
Ig another way of explaining would be

This renders the server component client-side
"use client"

function SomeClientComp() {
  return <Wrapper>
    <ServerComponent />
  </Wrapper>
}


Still renders the nested server component server-side
function SomeServerComp() {
  return <ClientSideWrapper>
    <ServerComponent/>
  </ClientSideWrapper>
}
emacs
Thanks! Great explanation
walid-mos
I would say just never use client component other than for client interaction (onClick, state ...), keep it atomic and just never import component in it

If you need to use it with other component, always use composition
@walid-mos I would say just never use client component other than for client interaction (onClick, state ...), keep it atomic and just never import component in it If you need to use it with other component, always use composition
emacs
This doesn’t fix the problem that many component libraries expect these to be client components and won’t work at all with a server component
@emacs This doesn’t fix the problem that many component libraries expect these to be client components and won’t work at all with a server component
American Chinchilla
The import is pretty much what matters here--if we import a server into a client, the server becomes a client. Client components can take server component children, however, and the server component children will remain server components provided they are imported into a server comp
@emacs This doesn’t fix the problem that many component libraries expect these to be client components and won’t work at all with a server component
walid-mos
You can call client component when you need, just make sure to never import server on client and everything will work just fine
Blue horntail woodwasp
What if you need to pull server/db information into a client side component though ?
@Blue horntail woodwasp What if you need to pull server/db information into a client side component though ?
American Chinchilla
Fetch in a server comp and pass as prop to client comp is the best way usually
Blue horntail woodwasp
Got it that makes sense
walid-mos
Ultimately you could use client side fetching, with packages as SWR for example

But i never saw a real advantage for the trade off it brings
@American Chinchilla The import is pretty much what matters here--if we import a server into a client, the server becomes a client. Client components can take server component children, however, and the server component children will remain server components provided they are imported into a server comp
emacs
So if you have a server component (SC) and that imports client and server components and that imported SC is a child of the client component, it will continue to function as a SC but if your importing a SC into a client component, then the SC will in effect be a client component
emacs
That helps considerably