Introduction 👋

The Server and Client Component model is the foundation of the Next.js App Router. It lets you choose, at the component level, whether code runs on the server, the client, or both — unlocking smaller bundles, direct backend access, and fine-grained interactivity. This tutorial covers the mental model, the rules, and the practical patterns for working with both.

What are Server Components? 🖥️

Server Components render exclusively on the server. Their code — including any imported libraries — is never sent to the browser, which keeps client bundles small. They can directly access backend resources like databases, file systems, or internal APIs.

export default async function Posts() {
  const posts = await db.query("SELECT * FROM posts");
  return <List type="unordered">{posts.map((p) => <List.Item key={p.id}>{p.title}</List.Item>)}</List>;
}

What are Client Components? 🖱️

Client Components render on the server for the initial HTML, then hydrate in the browser to become interactive. They support state, effects, event handlers, and browser-only APIs.

"use client";

import { useState } from "react";

export default function Counter() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>Count: {count}</button>;
}

Server Components vs Client Components ⚖️

React Server Components 🧠

React Server Components are a React architecture, not a Next.js-specific feature — Next.js is one of the first frameworks to implement them fully. RSC output isn't plain HTML; it's a special serialized format called the RSC Payload, which React uses to reconcile the UI.

The "use client" Directive 🏷️

Adding "use client" at the top of a file marks it — and everything it imports — as part of the client module graph. This is a boundary marker, not a per-component switch.

"use client";

import { useState } from "react";

export default function SearchBox() {
  const [query, setQuery] = useState("");
  return <input value={query} onChange={(e) => setQuery(e.target.value)} />;
}

The "use server" Directive 🏷️

"use server" marks a function (or entire file) as a Server Action — code that runs on the server but can be called directly from Client Components, commonly used for mutations like form submissions.

"use server";

export async function createPost(formData: FormData) {
  const title = formData.get("title");
  await db.insert({ title });
}

Component Boundaries 🚧

A boundary is created wherever "use client" appears. Everything imported below that file — even components without their own directive — becomes part of the client bundle.

Rendering Flow 🔀

On the initial request, Server Components render first, producing an RSC Payload that includes placeholders for Client Components. The server then renders everything to HTML, and the browser hydrates only the Client Component portions.

Data Fetching in Server Components 📡

Server Components can be declared async and use await directly in the component body — no useEffect or loading state management required.

export default async function Products() {
  const res = await fetch("https://api.example.com/products");
  const products = await res.json();
  return <List type="unordered">{products.map((p) => <List.Item key={p.id}>{p.name}</List.Item>)}</List>;
}

Data Fetching in Client Components 📡

Client Components fetch data using traditional React patterns: useEffect combined with useState, or a data-fetching library like SWR or React Query.

"use client";

import { useEffect, useState } from "react";

export default function LiveTicker() {
  const [price, setPrice] = useState<number | null>(null);

  useEffect(() => {
    const id = setInterval(async () => {
      const res = await fetch("/api/price");
      setPrice(await res.json());
    }, 5000);
    return () => clearInterval(id);
  }, []);

  return <p>Price: {price ?? "Loading…"}</p>;
}

Passing Data Between Components 🔁

Server Components can pass data down to Client Components as props, as long as that data is serializable. The reverse — passing functions or class instances from server to client — is not supported.

import LikeButton from "./LikeButton";

export default async function Page() {
  const post = await getPost();
  return <LikeButton initialLikes={post.likes} />;
}

Serialization Rules 📦

Props passed from Server to Client Components must be serializable — plain objects, arrays, strings, numbers, booleans, and a few special types. Functions, classes, and Symbols are not allowed, with the exception of Server Actions.

Interactivity in Client Components ⚡

Only Client Components can respond to user interaction through event handlers like onClick, onChange, and onSubmit, since these require JavaScript running in the browser.

"use client";

import { useState } from "react";

export default function Toggle() {
  const [open, setOpen] = useState(false);
  return <button onClick={() => setOpen(!open)}>{open ? "Hide" : "Show"}</button>;
}

Browser APIs 🌐

APIs like window, document, localStorage, and navigator only exist in the browser, so any code using them must live inside a Client Component.

"use client";

import { useEffect, useState } from "react";

export default function ThemeToggle() {
  const [theme, setTheme] = useState("light");

  useEffect(() => {
    setTheme(localStorage.getItem("theme") ?? "light");
  }, []);

  return <p>Current theme: {theme}</p>;
}

Server-Only Code 🔒

Code that should never reach the client — like secrets or direct database queries — can be explicitly protected using the server-only package, which throws a build error if accidentally imported into a Client Component.

import "server-only";

export async function getSecretData() {
  return db.query("SELECT * FROM secrets");
}

Client-Only Code 🔓

Conversely, the client-only package guards code that relies on browser APIs, throwing an error if it's accidentally imported into a Server Component.

import "client-only";

export function trackEvent(name: string) {
  window.dataLayer?.push({ event: name });
}

Shared Components 🤝

Components with no server- or client-only dependencies — like a simple <Button> — can be used in either context and will render according to whichever boundary imports them.

export default function Button({ children }: { children: React.ReactNode }) {
  return <button>{children}</button>;
}

Component Composition 🧩

A common and powerful pattern is passing Server Components into Client Components via the children prop. This lets server-rendered content live inside a client boundary without itself becoming a Client Component.

"use client";

export default function Modal({ children }: { children: React.ReactNode }) {
  return <div className="modal">{children}</div>;
}

import Modal from "@/components/Modal";
import ServerContent from "@/components/ServerContent";

export default function Page() {
  return (
    <Modal>
      <ServerContent />
    </Modal>
  );
}

Nesting Server and Client Components 🪆

Server Components can render Client Components, but Client Components cannot directly import Server Components — they can only receive them as children or other props from above.

Third-Party Libraries 📚

Many third-party components rely on hooks, context, or browser APIs but don't include their own "use client" directive. Wrapping them in your own Client Component file resolves this.

"use client";

import Carousel from "some-carousel-library";

export default function CarouselWrapper(props: any) {
  return <Carousel {...props} />;
}

Server Actions Overview 🛠️

Server Actions are asynchronous functions marked with "use server" that run on the server but can be invoked directly from Client Components — commonly used for form submissions and mutations, without manually building an API route.

"use server";

export async function subscribe(formData: FormData) {
  const email = formData.get("email");
  await db.subscribers.create({ email });
}

import { subscribe } from "@/app/actions";

export default function SubscribeForm() {
  return (
    <form action={subscribe}>
      <input name="email" type="email" />
      <button type="submit">Subscribe</button>
    </form>
  );
}

Performance Considerations 🚀

Bundle Size Optimization 📦

Keeping Client Components small and leaf-like in the component tree minimizes the JavaScript shipped to the browser, since only code below a "use client" boundary is bundled for the client.

SEO Considerations 🔍

Because both Server and Client Components produce HTML on the initial server render, content in either is crawlable — but relying on Server Components for primary content avoids any risk from client-side rendering delays or JS execution failures.

Migration Strategies 🔄

When migrating an existing client-heavy app to the Server Component model, a common approach is to start with everything as Server Components and add "use client" only where errors surface — such as missing hooks or event handlers.

Best Practices ✅

Common Mistakes ⚠️

Frequently Asked Questions 💬

Summary 📌