Chapter 110: Server Components

Core Idea

Server Components render exclusively on the server (or at build time) — never re-executed on the client, never shipping their own code to the browser bundle — letting a component read directly from a database/filesystem and pass only the resulting data down to interactive Client Components.

Key Concepts

• No 'use client' directive means "Server Component" by default in a framework configured for RSC — a component is a Server Component unless it (or an ancestor boundary) explicitly opts into 'use client' (Ch 112).
• Zero client bundle cost: a Server Component's own code (imports, logic) never ships to the browser at all — only the JSX/data it produces crosses to the client, which can meaningfully shrink bundle size for pages with heavy server-only logic.
• Direct backend access: a Server Component can await a database query or read a file directly in its body, without needing an API route as an intermediary — this is the core productivity/architecture shift RSC enables.
• Composition rule: a Server Component can render a Client Component (passing serializable props down), but a Client Component cannot import and render a Server Component directly — data/JSX flows from server to client, not the reverse; a Client Component can only receive a already-rendered Server Component as children/props passed to it from above.
• Streaming-friendly by nature: Server Components pair naturally with Suspense (Ch 70) and the streaming render APIs (Ch 106-107) — a slow-loading Server Component can suspend its boundary while the rest of the page streams in around it.

Code Examples

// Server Component (no directive needed) — runs only on the server
async function Talks({ confId }) {
  const talks = await db.talks.findAll({ confId }); // direct DB access, no API route
  return <TalkList talks={talks} />; // TalkList can be a Client Component
}

• What it demonstrates: a Server Component fetching directly from a database and passing the result down to a (possibly interactive, 'use client') child — none of Talks's own code or the database call ships to the browser.

Key Takeaways

1. Server Components never re-run on the client and never appear in the client bundle — treat them as the default for anything that doesn't need interactivity or browser APIs.
2. Data flows one direction through the composition rule: Server Components can render Client Components, never the reverse import direction.
3. This is the architectural foundation the "Directives" chapters (Ch 111-113) and streaming SSR chapters (Ch 106-107) build on.

Connects To

• Ch 112 ('use client'): the opt-out boundary into interactive, browser-executed components.
• Ch 111 (Server Functions): server-only functions callable from client code, the RSC counterpart to Server Components for behavior instead of rendering.
• Ch 7 (Creating a React App): Next.js's App Router as the most complete current RSC implementation.