React JS

Understanding React Server Components Explained Simply

By Utility Zone · 2025-11-01T18:06:46.319962

React Server Components (RSC) fundamentally change how React applications render. Instead of sending all component code to the browser, RSC lets you run specific components entirely on the server, sending only the rendered output to the client. This dramatically reduces the JavaScript bundle users must download while improving performance and security.¹²³

How React Server Components Work

By default, all React components in modern frameworks are server components—they render on the server and produce HTML. No client-side JavaScript is shipped for these components. You only mark a component as a client component with the 'use client' directive when it needs browser APIs, state, or interactivity.²⁴

When a server component fetches data, that data flows directly into the component during rendering, then the server sends serialized HTML to the browser. For client components within that tree, React sends them as lightweight JavaScript bundles with instructions on where to attach in the DOM.³⁵

The Three Rendering Approaches

Comparison of RSC, SSR, and Client Components Across Key Metrics

RSC works differently from SSR and pure client-side rendering in fundamental ways:

RSC (React Server Components): Server components never ship their code to the browser. They render completely on the server, and React sends only the rendered output plus lightweight client component bundles. This is ideal for data display, static content, and avoiding client-side waterfall requests.²³

SSR (Server-Side Rendering): The server renders HTML on each request, then the client downloads the same component logic to "hydrate" it with interactivity. Both the server and client execute the same component code, meaning full component logic ships to the browser. This improves first paint but still carries substantial bundle overhead.⁶³

Client Components: All rendering and data fetching happen in the browser. This was the traditional React model. Users see a blank screen until JavaScript downloads and executes, then wait for additional API calls to fetch data.²

The key distinction: RSC server code never reaches the browser, while SSR ships all code to both server and client.²

Pros and Cons Comparison

React Server Components Pros:

Dramatically smaller client bundles (expensive dependencies stay on server)¹³
Data fetching happens before rendering (no waterfall delays)³
Direct database access without API layers (cleaner architecture)⁷¹
Sensitive credentials never exposed to clients⁸
Seamless streaming and progressive rendering with Suspense³
Reduced Time-to-Interactive for users¹

React Server Components Cons:

Cannot use React hooks (useState, useContext, useEffect)²⁹
No access to browser APIs (localStorage, geolocation, etc.)¹
Mental model shift from traditional component architecture⁸
Limited tooling and third-party library support (still evolving)⁸
Requires compatible framework (Next.js 13+, etc.)⁸

SSR Pros:

Better initial page load than pure CSR⁶
Improved SEO (HTML available immediately)⁶
Reduces Time-to-First-Paint¹⁰
Works with all React components as-is⁶

SSR Cons:

Server strain under heavy traffic (generates full HTML per request)¹⁰
Double rendering work (server + client hydration)²⁶
Still ships full component logic to browser²
Hydration delay before interactivity¹⁰

Client Components Pros:

Full browser API access²
Familiar mental model for interactive features¹
Instant updates with state changes²

Client Components Cons:

Large JavaScript bundles³²
Slower first page load³
Network waterfalls for data fetching⁶³
Cannot directly access secure data sources³

Migration Example: Converting a Client Widget to Server Component

The Before State

A typical client component might fetch product data in useEffect, manage loading/error states, and struggle with network waterfalls:

'use client';
import { useState, useEffect } from 'react';

export default function ProductList() {
  const [products, setProducts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/products')
      .then(r => r.json())
      .then(data => {
        setProducts(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <div>Loading...</div>;
  return (
    <div>
      {products.map(p => (
        <ProductCard key={p.id} product={p} />
      ))}
    </div>
  );
}

Problems: Extra network request after initial render, all this component's code shipped to browser, useEffect hook overhead, loading state management complexity.

The After State

As a server component with async/await:

// No 'use client' - renders on server by default
import { Suspense } from 'react';
import { getProducts } from '@/lib/products';
import ProductLoadingSkeleton from './ProductLoadingSkeleton';

export default async function ProductList() {
  // Direct await in render - data fetches during rendering
  const products = await getProducts();

  return (
    <div>
      {products.map(p => (
        <ProductCard key={p.id} product={p} />
      ))}
    </div>
  );
}

// Wrap with Suspense for loading UI
export function ProductListWithSuspense() {
  return (
    <Suspense fallback={<ProductLoadingSkeleton />}>
      <ProductList />
    </Suspense>
  );
}

Improvements: Zero client JavaScript for this component, data ready during render (no extra request), cleaner async/await syntax, Suspense handles loading states elegantly.

Data Fetching Layer

Create a server-only module that databases can safely query:

// lib/products.ts - never shipped to client
import { db } from '@/lib/db';

export async function getProducts() {
  return db.product.findMany({
    select: {
      id: true,
      name: true,
      price: true,
    },
  });
}

Splitting Interactivity into Client Components

When interactivity is needed (like "Add to Cart"), extract it into a separate client component that receives serializable props:⁵

// ProductCard.tsx (Server Component - display only)
import AddToCartButton from './AddToCartButton';

export default function ProductCard({ product }) {
  return (
    <div>
      <h3>{product.name}</h3>
      <span>${product.price}</span>
      {/* Only this part runs on client */}
      <AddToCartButton productId={product.id} />
    </div>
  );
}

// AddToCartButton.tsx (Client Component - interactivity only)
'use client';
import { useState } from 'react';

export default function AddToCartButton({ productId }) {
  const [added, setAdded] = useState(false);

  const handleClick = async () => {
    await fetch('/api/cart', {
      method: 'POST',
      body: JSON.stringify({ productId }),
    });
    setAdded(true);
  };

  return (
    <button onClick={handleClick}>
      {added ? 'Added!' : 'Add to Cart'}
    </button>
  );
}

This pattern ensures only the button logic ships to the client, while the entire product display renders on the server.⁵

Project Folder Structure

A well-organized Next.js project using RSC follows this structure:

app/                          # Routes and pages
├── layout.tsx               # Root layout
├── page.tsx                 # Home page
└── products/
    └── page.tsx             # /products route

components/
├── ui/                      # Reusable UI blocks
│   ├── Button/
│   └── Card/
├── features/                # Feature-specific components
│   ├── products/
│   │   ├── ProductList.tsx         # Server
│   │   ├── ProductCard.tsx         # Server
│   │   └── AddToCartButton.tsx     # Client
│   └── dashboard/
└── layout/                  # Page layout sections

lib/                         # Server-safe utilities
├── products.ts            # Data fetching
├── db.ts                  # Database client
└── types.ts               # TypeScript definitions

In this structure, components without 'use client' are server components by default. Only components that need browser interactivity get the directive. The lib/ folder contains server-only code that fetches from databases or secure APIs.¹¹¹²

Best Practices for RSC Migration

Start with an incremental approach: add 'use client' to your root component, then gradually move the directive lower in the tree as you replace data-fetching logic with async server components. Use Suspense boundaries to handle loading states elegantly—wrap server components with <Suspense fallback={<Skeleton />}> for progressive rendering.¹³¹⁴¹⁵

Keep serializable props only when passing data from server to client components; avoid functions or class instances. This ensures React can safely transmit data across the server-client boundary.²⁹

Use error boundaries for graceful error handling in server components, and combine them with Suspense for complete async state management. For real-time data that needs updates, pass promises from server to client and resolve them using the use() hook.¹⁶¹⁷

Remember that framework implementations like Next.js handle the streaming and serialization automatically—you simply write async components and let the framework handle delivery to clients.³ <span style="display:none">¹⁸¹⁹²⁰²¹²²²³²⁴²⁵²⁶²⁷²⁸²⁹³⁰³¹³²³³³⁴³⁵³⁶³⁷³⁸</span>