Server Components & Next.js

The modern full-stack React model - what Server Components are, how they differ from Client Components, and why Next.js exists.

What it is, in plain English: React Server Components (RSC) are components that render on the SERVER and send the result to the browser as a compact format -- not as JavaScript the browser has to execute. They can directly access databases and the filesystem, never ship their code to the client, and reduce the JavaScript bundle size. Client Components (marked with 'use client') are the React you already know -- they run in the browser and can use hooks and interactivity. Next.js is the most popular framework implementing this model.

React that runs on the server, not just the browser

Everything covered so far runs in the browser -- React renders, useState updates, useEffect fires, all client-side. React Server Components introduce a second kind of component that runs ONLY on the server, never shipping its code to the browser at all.

The two kinds of components

// SERVER COMPONENT (the default in Next.js App Router) -- no directive needed:
// app/page.js
async function HomePage() {
  // Can directly query a database, read files, use server-only secrets:
  const posts = await db.posts.findMany();

  return (
    <div>
      <h1>Blog</h1>
      {posts.map(post => <article key={post.id}>{post.title}</article>)}
    </div>
  );
}
// This component's CODE never reaches the browser -- only its rendered HTML output.
// No useState, no onClick, no useEffect allowed here -- it's not interactive.

// CLIENT COMPONENT -- needs the "use client" directive at the top of the file:
"use client";

import { useState } from "react";

function LikeButton() {
  const [liked, setLiked] = useState(false);   // hooks work here

  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? "❤️ Liked" : "🤍 Like"}
    </button>
  );
}
// THIS component's code DOES ship to the browser, because it needs
// to run there to handle clicks and manage state.

Why this distinction exists

// Before Server Components, ALL React code shipped to the browser as JavaScript,
// even components that just fetched data and displayed it -- no interactivity needed.
// This meant: bigger JS bundles, slower initial load, and a round-trip
// (fetch on the server for an API, then fetch AGAIN from the browser).

// Server Components fix this:
// - Zero JavaScript shipped for non-interactive parts of the page
// - Direct backend access (database, filesystem) -- no API layer needed
// - Smaller bundles = faster page loads
// - Secrets (API keys, DB credentials) never reach the browser

What Next.js actually is

// Next.js is a FRAMEWORK built on React that adds:
// - File-based routing (app/products/page.js = /products route)
// - Server Components by default (App Router)
// - Built-in data fetching, image optimization, font optimization
// - API routes (app/api/users/route.js)
// - Deployment optimizations (especially on Vercel)

// React alone = just the UI library (components, hooks, rendering)
// Next.js = React + routing + server rendering + build tooling + conventions

Try It Yourself (JSX)

// React Server Components -- conceptual overview
// (RSC requires a framework like Next.js to run -- shown here as reference code,
//  Try It runs regular client-side React since RSC needs a server)

const RSC_EXAMPLE = `
// app/products/page.js -- a SERVER COMPONENT by default in Next.js App Router
// No "use client" directive = this runs ONLY on the server

import { db } from "@/lib/db";

export default async function ProductsPage() {
  // Direct database access -- no API route needed, no fetch(), no useEffect!
  // This code NEVER ships to the browser as JavaScript:
  const products = await db.products.findMany();

return (
    <div>
      <h1>Products</h1>
      <ProductList products={products} />
    </div>
  );
}
`;

const CLIENT_COMPONENT_EXAMPLE = `
// app/components/AddToCartButton.js -- a CLIENT COMPONENT
"use client";   // <- this directive marks the boundary

import { useState } from "react";

export default function AddToCartButton({ productId }) {
  const [added, setAdded] = useState(false);   // hooks need a Client Component

function handleClick() {
    addToCart(productId);
    setAdded(true);
  }

return <button onClick={handleClick}>{added ? "Added!" : "Add to Cart"}</button>;
}
`;

console.log("Server Component (default in Next.js App Router):");
console.log(RSC_EXAMPLE.trim());
console.log("\nClient Component (opt-in with 'use client'):");
console.log(CLIENT_COMPONENT_EXAMPLE.trim());

console.log("\nKey rule: Server Components can import Client Components,");
console.log("but Client Components CANNOT import Server Components directly.");
console.log("Interactivity (useState, onClick, useEffect) always needs 'use client'.");

function App() {
  return <p>RSC needs a server runtime -- see the code examples above for the real pattern.</p>;
}

Composition rules and Server Actions

The composition rule -- Server can import Client, not the reverse

// ✓ ALLOWED: a Server Component renders a Client Component:
// app/page.js (Server Component)
import LikeButton from "./LikeButton";   // Client Component

export default async function Page() {
  const post = await db.posts.findFirst();
  return (
    <article>
      <h1>{post.title}</h1>       {/* rendered on server, no JS shipped */}
      <LikeButton postId={post.id} />  {/* this part becomes interactive client JS */}
    </article>
  );
}

// ✗ NOT ALLOWED: a Client Component cannot import a Server Component directly
// (because Server Components need server-only APIs like database access,
//  which simply don't exist once code is running in the browser)

// The workaround: pass Server Component output as 'children' to a Client Component:
// app/page.js (Server):
<ClientWrapper>
  <ServerComponent />   {/* rendered on server, passed as children */}
</ClientWrapper>

Server Actions -- mutations without an API route

// app/actions.js
"use server";   // marks these functions as Server Actions

export async function addTodo(formData) {
  const text = formData.get("text");
  await db.todos.create({ data: { text } });
}

// app/page.js -- use it directly in a form, no API endpoint needed:
import { addTodo } from "./actions";

export default function TodoPage() {
  return (
    <form action={addTodo}>
      <input name="text" />
      <button type="submit">Add</button>
    </form>
  );
}
// The form submission calls addTodo() ON THE SERVER directly --
// no fetch(), no API route, no JSON serialization to write manually.

Streaming and Suspense

import { Suspense } from "react";

export default function Page() {
  return (
    <div>
      <Header />   {/* renders immediately */}
      <Suspense fallback={<Spinner />}>
        <SlowComments />   {/* streams in once its data is ready */}
      </Suspense>
    </div>
  );
}
// The page shell loads instantly; slow parts stream in as they become ready,
// instead of blocking the entire page behind the slowest piece of data.

RSC payload format and hydration

// Server Components don't send HTML directly -- they send a special
// serialized format (the "RSC payload") that describes the component tree,
// including references to where Client Components should be hydrated:

// Simplified conceptual shape of what's sent over the wire:
// 0:["$","div",null,{"children":[
//     ["$","h1",null,{"children":"Blog"}],
//     ["$","@1",null,{"postId":42}]    <- reference to a Client Component
// ]}]
// 1:I{"id":"./LikeButton.js","chunks":[...],"name":"default"}

// The browser receives this payload, renders the static parts immediately,
// and hydrates ONLY the Client Component boundaries with their JS bundles --
// not the entire page.

Hydration — connecting server-rendered HTML to live React

Hydration is the process of attaching React's event handlers and internal state to HTML that was already rendered (either by a Server Component or traditional SSR). The browser receives ready-to-display HTML immediately (fast First Contentful Paint), then React "hydrates" it — walking the existing DOM and attaching the interactive behaviour, rather than tearing it down and re-rendering from scratch. A hydration mismatch (server-rendered HTML differing from what the client would render) causes errors — commonly from using Date.now(), Math.random(), or browser-only APIs during server rendering, where the server and client compute different output for the same component.

Official Sources

The Codex links only to official documentation. No third-party tutorials.