Server and Client Components

Next.js App Router ships with a deceptively simple mental model: every component is either a Server Component or a Client Component. ¹ Get the split right and you gain free server-side rendering, zero-cost data fetching, and a smaller JavaScript bundle. Get it wrong and you silently pull your entire page into the browser bundle, losing all of those benefits.

This note walks through what each type actually is, what rules they follow, and the exact patterns for composing them together.

#Two Rendering Environments

Before "Server Component" or "Client Component" means anything, you have to understand that your code now runs in two fundamentally different places.

The server environment is a Node.js process. It has access to the file system, databases, environment secrets, and the full node: API surface. It has no window, no document, and no DOM.

The client environment is the browser. It has window, document, event listeners, and React's stateful hooks. It cannot touch databases or secret environment variables directly.

The table above is the single most useful thing to memorise. Every "why doesn't this work?" question about Server and Client Components traces back to one of these environment mismatches.

#React Server Components

React Server Components (RSC) are the default in Next.js App Router. Any .tsx file in the app/ directory that does not begin with "use client" is a Server Component.

The headline feature is that an RSC can be an async function. You await your data directly in the component body — no useEffect, no loading state, no client-side waterfall.

// app/articles/page.tsx  — Server Component by default
export default async function ArticlesPage() {
  const articles = await db.query('SELECT * FROM articles ORDER BY date DESC')

  return (
    <ul>
      {articles.map(a => <li key={a.id}>{a.title}</li>)}
    </ul>
  )
}

// No "use client" → Server Component
// This entire file stays on the server.
import { marked } from 'marked'        // 200 kB library
import { db } from '@/lib/database'    // secret credentials

export default async function Post({ slug }: { slug: string }) {
  const post = await db.posts.findUnique({ where: { slug } })
  const html = marked(post.content)    // runs server-side
  return <article dangerouslySetInnerHTML={{ __html: html }} />
}

What a Server Component cannot do:

• Use useState, useReducer, useEffect, or any React hook that requires a live browser runtime
• Attach event handlers like onClick or onChange
• Access window, document, localStorage, or any other browser API

#Client Components

A Client Component is any component whose file begins with the "use client" directive. This is the boundary declaration — it tells Next.js that this file (and everything it imports) should be included in the browser JavaScript bundle and hydrated client-side.

// components/ThemeToggle.tsx
"use client"
// ↑ This one line is the entire "use client" directive.
//   It tells Next.js to include this file in the client bundle.

import { useState } from "react"

export function ThemeToggle() {
  const [dark, setDark] = useState(false)
  return (
    <button onClick={() => setDark(d => !d)}>
      {dark ? "Light mode" : "Dark mode"}
    </button>
  )
}

"use client"
// ↑ must be the first line — before imports

import { useState, useEffect } from "react"
import { cn } from "@/lib/utils"

// This file now participates in the browser bundle.
// useState, useEffect, onClick — all valid here.

What a Client Component can do that a Server Component cannot:

• Call useState, useReducer, useContext, useRef, and all other React hooks
• Register event handlers (onClick, onChange, onSubmit, …)
• Access window, document, navigator, localStorage
• Use browser-specific APIs like IntersectionObserver, ResizeObserver, or the Web Audio API
• Re-render in response to user interaction without a server round-trip

#The "use client" Boundary

"use client" does not mark a single component — it marks a subtree boundary. Every file that a Client Component imports directly becomes part of the client bundle too, regardless of whether those files have their own "use client" directive.

Switch between the three scenarios above. The key insight:

• Leaf-level client — "use client" appears only on the components that actually need it. The server forms the skeleton; client components are small, focused islands.
• Too much client — "use client" is placed on a high-level component. Every child it imports becomes a client component, losing server features and inflating the JS bundle.
• SC as CC children — Server Component output is passed as children to a Client Component. The SC still runs on the server.

layout.tsx  (Server)
  └─ Page  (Server)
       └─ Sidebar  (Server)
            └─ FilterForm  ← "use client" boundary
                 └─ FilterInput  (Client)  ← pulled in as client
                 └─ ResetButton  (Client)  ← pulled in as client

#Composition Patterns

There are four patterns to know. Three are valid; one is a common mistake.

The children pattern deserves a concrete example. Instead of the Client Component importing the Server Component, the Server Component parent renders both and passes the SC's output as children:

// app/page.tsx — Server Component
import { Modal } from '@/components/Modal'
import { ArticleContent } from '@/components/ArticleContent'

export default async function Page({ params }) {
  return (
    <Modal>
      <ArticleContent slug={params.slug} />
    </Modal>
  )
}

// components/Modal.tsx
"use client"
import { useState } from "react"

export function Modal({ children }: { children: React.ReactNode }) {
  const [open, setOpen] = useState(true)
  return open ? <dialog>{children}</dialog> : null
}

// Props that CAN cross the boundary:
<ClientComp name="Alice" count={42} tags={["a", "b"]} />

// Props that CANNOT cross the boundary:
<ClientComp onUpdate={() => refetch()} />  // ✗ function
<ClientComp instance={new MyClass()} />    // ✗ class instance
<ClientComp data={new Map([...])} />       // ✗ Map / Set

// Exception: children (React nodes from SC are OK)
<ClientComp><ServerComp /></ClientComp>    // ✓

#A Practical Example: Building a Blog

All of the rules above click into place fastest with a concrete project. A blog has a natural split: the content and data-fetching are purely server-side work; the interactive features — liking a post, adding a comment, copying a share link — belong to the client.

Click any node in the tree to see its role and code. The structure has two routes:

• posts/page.tsx — lists all posts. It fetches from the database, renders PostList → PostCard, and streams pre-filled HTML. No JavaScript is sent for any of these components.
• posts/[slug]/page.tsx — renders a single post. It fetches the post, parses Markdown on the server using a potentially large library (zero bundle cost), and composes three Client Components at the leaves.

The three Client Component leaves — LikeButton, ShareMenu, CommentSection — are small and focused. Each one has a single reason to be a Client Component:

// components/LikeButton.tsx
"use client"
export function LikeButton({ postId, initialLikes }) {
  const [likes, setLikes] = useState(initialLikes)
  async function handleLike() {
    setLikes(l => l + 1)
    await fetch(`/api/posts/${postId}/like`, { method: "POST" })
  }
  return <button onClick={handleLike}>♥ {likes}</button>
}

// components/ShareMenu.tsx
"use client"
export function ShareMenu({ title }) {
  const [open, setOpen] = useState(false)
  function copyLink() {
    navigator.clipboard.writeText(window.location.href)
  }
  return (
    <div>
      <button onClick={() => setOpen(o => !o)}>Share</button>
      {open && <button onClick={copyLink}>Copy link</button>}
    </div>
  )
}

// components/CommentSection.tsx
"use client"
export function CommentSection({ postId }) {
  const [comments, setComments] = useState([])
  const [text, setText] = useState("")
  async function submit(e) {
    e.preventDefault()
    setComments(c => [...c, { text, id: Date.now() }])
    setText("")
    await fetch(`/api/posts/${postId}/comments`, {
      method: "POST", body: JSON.stringify({ text }),
    })
  }
  return (
    <section>
      {comments.map(c => <p key={c.id}>{c.text}</p>)}
      <form onSubmit={submit}>
        <textarea value={text} onChange={e => setText(e.target.value)} />
        <button type="submit">Post</button>
      </form>
    </section>
  )
}

The Server Component pages never import these three files directly — they just render them inline. The "use client" boundary on each file ensures only the code for those small components ends up in the browser bundle. Everything else — the page shells, PostList, PostCard, the Markdown parser — stays on the server.

#Data Fetching

The two component types naturally suggest two data-fetching strategies.

Server Components — fetch at render time

Because RSCs are async, they can await any data source directly. No hooks, no loading spinners, no client-side waterfall. The HTML arrives pre-filled.

// Server Component — async, direct DB access
export default async function Dashboard() {
  const [stats, recentOrders] = await Promise.all([
    db.getStats(),
    db.getRecentOrders({ limit: 10 }),
  ])

  return (
    <main>
      <StatsGrid data={stats} />
      <OrderTable orders={recentOrders} />
    </main>
  )
}

Client Components — fetch after interaction

When data depends on user input, live subscriptions, or must update without a full page reload, the Client Component handles it with hooks or a data-fetching library.

"use client"
import useSWR from "swr"

export function LivePrice({ ticker }: { ticker: string }) {
  const { data, isLoading } = useSWR(`/api/price/${ticker}`, fetcher, {
    refreshInterval: 5000,
  })

  if (isLoading) return <span>—</span>
  return <span>${data.price.toFixed(2)}</span>
}

The common hybrid: a Server Component fetches the initial data and passes it to a Client Component as initialData. The CC can optimistically update from there without blocking the initial paint.

#When to Use Which

The guiding principle: start with a Server Component and reach for "use client" only when you need something the browser provides.

#A Mental Model

The practical rule is simple: the boundary is a one-way valve. Data and rendered nodes flow from server to client; JavaScript and interactivity flow from client to user.

When a component is in the wrong environment — hooks in a Server Component, database calls in a Client Component — the error message almost always tells you exactly which rule was broken. With this model in mind, the fix is usually one line: add or remove "use client", or restructure to use the children composition pattern.