-
SummaryHi everyone, I'm a bit confused about the exact criteria for deciding whether a component should be a Server Component or a Client Component. I’ve read the documentation, but it still feels a bit unclear to me. Should only components that fetch data be Server Components? And should only interactive components be Client Components? For example, if I have a navigation bar with several buttons (e.g. logo, login button, user menu), and I need to fetch data for it—could the Navigation component be a Server Component that handles the data fetching and passes the data down to Client Components like the buttons? One of my team argued that "Navigation itself should be considered an interactive component, so it must be a Client Component." Based on that, he also suggested that aside from page.tsx and layout.tsx, we shouldn't make anything a Server Component. Isn’t that a bit extreme? For something like a Navigation component—which is highly reusable—wouldn't it make sense to implement it as a Server Component that fetches the necessary data and then renders Client Components for interactive parts? I’d love to hear your thoughts and how your teams are handling this. Thanks in advance! Additional informationNo response ExampleNo response |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
Keep shining bro... |
Beta Was this translation helpful? Give feedback.
-
Hi @kkjjss, the great advantage of server components is that the javascript code is run on the server only - only HTML is sent to the client, there is no need to hydrate anything. You could build your whole dynamic web page as server components and the result would be pure HTML page with almost no additional Javascript. Client components, on the other hand, need to be hydrated - and will then execute the code on the client. Next.js renders even client components on the server, and sends some initial HTML, so the differences are in reality a bit smaller - but the code for the components must be delivered to the client, so the resulting JS bundle will be bigger and the whole page will take longer before becoming interactive. The difference becomes apparent with fetching data. If you want to fetch data on every request (let's say your page displays the current stock market prices), you can do it in a server component on the server side (the rendering would have to wait until the data is loaded), but you don't need to expose your API (or your credentials) to the client and you'd send the data in the initial load as part of the HTML structure. If you want to fetch data in a client component (in You can combine server components with client components. The rule of thumb for me is to use server component everywhere I can and only use client components if I need interactivity ( To elaborate on your Navigation component. Let's say you need to fetch the menu structure (links, subsections etc.). I would do that fetch in the parent server component ( The result could look like this: export async function Navigation() {
const menuItems = await fetchMenuItems();
const userSession = await getUserSessionFromCookies();
return (
<nav>
<Logo /> {/* server component */}
{menuItems.map(item => (
<Link key={item.id} href={item.url}>{item.title}</Link>
}
{!userSession && <LoginButton />} {/* a server component that is shown only if user is not logged in */}
{userSession && <UserMenu session={userSession} />} {/* a server component that shows user menu if user is logged in */}
</nav>
);
} |
Beta Was this translation helpful? Give feedback.
Hi @kkjjss,
the great advantage of server components is that the javascript code is run on the server only - only HTML is sent to the client, there is no need to hydrate anything. You could build your whole dynamic web page as server components and the result would be pure HTML page with almost no additional Javascript. Client components, on the other hand, need to be hydrated - and will then execute the code on the client. Next.js renders even client components on the server, and sends some initial HTML, so the differences are in reality a bit smaller - but the code for the components must be delivered to the client, so the resulting JS bundle will be bigger and the whole page will take …