The team starts a Next.js 14 project. The first PR is full of "use client" at the top of every component, “just to be safe.” A senior engineer asks why. Nobody knows; everyone is confused about which components should be server and which client. The bundle size for the homepage is 800 KB of JS for a page that mostly displays static content.

React Server Components (RSC) is the most-misunderstood frontend feature of the past few years. The reason is mostly that the mental model from “regular React” doesn’t translate. Once you have the right model, the "use client" boundary becomes an obvious answer to one question: does this component need to be reactive on the user’s machine?

This post is the model, applied to a few real component patterns, with the four traps that cause most teams to mis-mark components.

The core idea

A React Server Component:

• Renders only on the server.
• Has access to the database, file system, secrets, and any Node.js API.
• Ships its output as HTML/JSON to the browser, but the component code itself is not in the bundle.
• Cannot use hooks (useState, useEffect), event handlers (onClick), or browser APIs.

A Client Component:

• Renders on both server (SSR) and client.
• Hydrates on the client; can use hooks, events, browser APIs.
• The code is in the bundle.

The boundary between them is "use client" at the top of a file. Anything below that file’s exports is a client component (and so are any imports).

The mental model: reactivity boundary

Ask one question per component: “Does this component need to be reactive on the user’s machine?”

• “It just shows data” → server component.
• “It has a button that does something” → client component.
• “It uses useState, useEffect, etc.” → client component.
• “It needs to access the URL or browser APIs” → client component.

Most components (typography, layout, anything that just renders props) should be server components. The “client” boundary should be small islands at the leaves of the tree, not the whole tree.

A worked example

A typical product page:

// app/products/[id]/page.tsx - Server Component (default in Next.js app dir)
import { db } from '@/lib/db';
import { AddToCartButton } from './add-to-cart-button';
import { Reviews } from './reviews';

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await db.products.findUnique({ where: { id: params.id } });

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <p>${product.priceCents / 100}</p>
      <AddToCartButton productId={product.id} />
      <Reviews productId={product.id} />
    </div>
  );
}

// app/products/[id]/add-to-cart-button.tsx - Client Component
'use client';
import { useState } from 'react';

export function AddToCartButton({ productId }: { productId: string }) {
  const [adding, setAdding] = useState(false);

  return (
    <button
      onClick={async () => {
        setAdding(true);
        await fetch(`/api/cart`, { method: 'POST', body: JSON.stringify({ productId }) });
        setAdding(false);
      }}
      disabled={adding}
    >
      {adding ? 'Adding...' : 'Add to cart'}
    </button>
  );
}

// app/products/[id]/reviews.tsx - Server Component
import { db } from '@/lib/db';

export async function Reviews({ productId }: { productId: string }) {
  const reviews = await db.reviews.findMany({ where: { productId } });
  return (
    <ul>
      {reviews.map(r => <li key={r.id}>{r.rating} - {r.body}</li>)}
    </ul>
  );
}

Notice: the page accesses the database directly. The reviews component does too, server-to-server, no API call needed. The Add-to-Cart button is the only client component, and only because it has a useState and a click handler. Bundle size for this page: just the button.

The four traps

1. Marking a parent as "use client" because a child needs it. A common reaction: “the button needs "use client", so let me mark the page too.” Wrong direction. The "use client" directive applies to the file where it appears and any imports below it. The parent stays a server component; only the leaf component is client.

2. Trying to use hooks in a server component. A server component has no useState, useEffect, or useRef. If you need them, the component must be client. The error message (“Hooks can only be used inside the body of a function component”) points at this.

3. Passing functions from server to client components. Server components can pass props to client components, but functions are not serializable.

// SERVER COMPONENT:
const onSubmit = async (data) => { /* ... */ };
return <ClientForm onSubmit={onSubmit} />;  // ← error: function is not serializable

The fix: use Server Actions (async function action(...) marked "use server").

4. Importing client-only libraries in server components. A library that uses window, document, or browser APIs cannot run on the server. Either: "use client" the importing component, or wrap the library in a dynamic import that runs only on the client.

Server Actions

Server Actions are the missing piece that makes RSC ergonomic for forms and mutations:

// app/actions.ts
'use server';

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

export async function addToCart(productId: string) {
  await db.cart.upsert({
    where: { userId: getCurrentUserId() },
    create: { items: [{ productId }] },
    update: { items: { push: { productId } } },
  });
}

// AddToCartButton.tsx - Client Component
'use client';
import { addToCart } from '@/app/actions';

export function AddToCartButton({ productId }: { productId: string }) {
  return (
    <form action={() => addToCart(productId)}>
      <button>Add to cart</button>
    </form>
  );
}

The button is a client component (event handler, possibly useState for loading); the action runs on the server and has direct DB access. No API endpoint to write.

The right boundary placement

A heuristic that works: draw the smallest possible client component, push it as far down the tree as possible.

If you have a large component that mostly renders data and has one interactive piece, refactor:

// Before: whole component is client because of one button.
'use client';
export function ArticlePage({ articleId }) {
  const [bookmarked, setBookmarked] = useState(false);
  // ... 200 lines of mostly static rendering ...
  return <div>{/* ... */} <button onClick={...}>bookmark</button></div>;
}

// After: page is server, button is a tiny client component.
export async function ArticlePage({ articleId }) {
  const article = await db.articles.findUnique(...);
  return <div>
    <h1>{article.title}</h1>
    <p>{article.body}</p>
    <BookmarkButton articleId={article.id} />
  </div>;
}

Bundle size collapses. Most rendering happens on the server.

Streaming and Suspense

RSC integrates with React Suspense for streaming:

import { Suspense } from 'react';

export default async function Page() {
  return (
    <div>
      <Header />  {/* renders fast */}
      <Suspense fallback={<Spinner />}>
        <SlowReviews productId="..." />  {/* streamed when ready */}
      </Suspense>
    </div>
  );
}

The browser receives the header HTML immediately and streams the Reviews HTML when the database query finishes. Time-to-first-byte stays fast, time-to-interactive is correct.

This is one of RSC’s bigger wins: it makes streaming the default rather than an opt-in optimization.

Caching and data fetching

In Next.js App Router, fetch() is automatically cached and deduplicated across components in the same request:

// Both components fetch, but Next.js makes only one network call.
async function ParentComp() {
  const data = await fetch('https://api.example.com/foo').then(r => r.json());
  // ...
}

async function ChildComp() {
  const data = await fetch('https://api.example.com/foo').then(r => r.json());
  // ...
}

Customize via { next: { revalidate: 60 } } (cache for 60 seconds) or { cache: 'no-store' } (always fresh).

For database calls, you implement caching yourself or use cache() from React.

When NOT to use RSC

A few cases:

• Mostly-interactive apps (a SaaS dashboard with rich UI everywhere). Pure SPA might be cleaner.
• Heavy reliance on a non-RSC-ready ecosystem. Some libraries don’t work as server components yet; check before committing.
• Edge runtime constraints. RSC works best with full Node.js; some edge runtimes have limitations.

For most marketing sites, content sites, and admin panels with mixed interactivity, RSC is the right default.

The takeaway

The mental model: “does this component need to be reactive on the user’s machine?” If yes, client component. If no, server component. Most components are server components; client components are small leaves at the bottom of the tree. Pass data down, mark interactive bits as client, use Server Actions for mutations.

The team that internalizes this ships pages with 50 KB of JS instead of 500 KB. The ones that don’t paste "use client" at the top of everything and lose the entire benefit.

A note from Yojji

The kind of frontend architecture judgment that takes advantage of new React capabilities, keeping bundles small with the right server/client split, is the kind of detail Yojji’s frontend teams put into the products they ship for clients.

Yojji is an international custom software development company founded in 2016, with teams across Europe, the US, and the UK. They specialize in the JavaScript ecosystem (React, Node.js, TypeScript), cloud platforms, and full-cycle product engineering, including the React Server Component architecture decisions that decide whether a site feels fast or merely modern.