Server Components are rendered on the server, do not increase the size of the client, and are suitable for data acquisition and static content; Client Components run in the browser, supporting interaction and state management. 1. Server Components cannot use hooks such as useState and can directly access the database; 2. Client Components need to be declared with 'use client' to handle events and side effects; 3. Client components can be embedded in server components, but not vice versa; 4. Prioritize using Server Components to reduce JS packaging volume and improve performance; 5. Use Client Components when interaction is required. Only by correct division of labor can the advantages of React's new architecture be brought into play.

React Server Components (RSC) and Client Components are two component models introduced in React 18. They are essentially different in rendering timing, running environment, and usage scenarios. Understanding their differences and how they work together is critical to building high-performance, maintainable, modern React applications.

What are Server Components and Client Components?

Server Components

• Rendering on the server does not consume the client's JavaScript package size .
• Hooks such as useState and useEffect cannot be used because they do not run in the browser.
• Backend resources (such as databases, file systems) can be accessed directly without additional API calls.
• The rendering results are sent to the client in a lightweight JSON structure, which is "reorganized" into DOM by React on the client side.

Client Components

• Running in the browser, interactive logic (event handling, state management, side effects, etc.) can be used.
• Will increase the packaging size, each imported library or Hook will be included in the JS bundle.
• Suitable for handling user interaction, animation, browser API (such as localStorage), etc.

? Simply put:

• Server Components: Responsible for data acquisition and static content rendering (faster and lighter)
• Client Components: responsible for interaction and dynamic behavior

How to distinguish Server and Client Components?

Starting with React 18, Next.js (App Router) is distinguished by a file naming convention:

• Server Component (default) : ordinary .js/.tsx file, no special tags.
• Client Component : The 'use client' directive must be written at the top of the file.

 // ClientComponent.tsx
'use client';

import { useState } from 'react';

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

 // ServerComponent.tsx
import ClientComponent from './ClientComponent';
import { fetchData } from './api';

export default async function ServerComponent() {
  const data = await fetchData(); // Call return directly on the server (
    <div>
      <h1>{data.title}</h1>
      <ClientComponent /> {/* Embed client component*/}
    </div>
  );
}

? Notice:

• Client components can be embedded in server components, but not the other way around.
• 'use client' must be the first line of the file (even if there is a comment before it).

Comparison of core advantages

Practical suggestions for use: How to choose?

? Prioritize using Server Components when:

• Mainly display content (articles, product details, lists)
• Need to get data from database or CMS
• Use large libraries (such as Markdown parsers, charting tools), but no interaction is required
• Want to reduce client side loading time (TTFB is faster, JS is less)

? Use Client Components when:

• Requires useState , useEffect , custom Hook
• There are interactions such as button clicks, form submissions, and animations.
• Depends on browser API ( window , localStorage , navigator )
• Use third-party UI libraries (such as Tailwind UI, Radix components)

Common misunderstandings and precautions

• Myth 1: Server Components = SSR
  Not entirely true. SSR (Server Side Rendering) renders the entire page into HTML on the server side, but all components are still downloaded to the client to "hydrate". RSC only runs some components on the server side and never transmits them to the client .

• Misunderstanding 2: Server Components cannot pass props to Client Components
  Can! But note:

  • The props passed must be serializable (functions, Date, Map, etc. cannot be passed)
  • Functions need to be handled indirectly through useActionState or event callbacks

• Performance Pitfall: Overuse of Client Components
  If the entire page is made into a Client Component, it will degenerate into a traditional SPA and lose the advantages of RSC. Try to move non-interactive parts to Server Component.

Best practice examples

 // app/page.tsx - Server Component
import ProductList from './ProductList'; // Client Component
import { getProducts } from '@/lib/database';

export default async function Home() {
  const products = await getProducts(); // Check the database directly return (
    <main>
      <h1>Product list</h1>
      <ProductList products={products} />
    </main>
  );
}

 // app/ProductList.tsx - Client Component
'use client';

import { useState } from 'react';

export default function ProductList({ products }) {
  const [filter, setFilter] = useState('');

  const filtered = products.filter(p =>
    p.name.includes(filter)
  );

  return (
    <div>
      <input 
        value={filter} 
        onChange={(e) => setFilter(e.target.value)} 
        placeholder="Search products"
      />
      <ul>
        {filtered.map(p => (
          <li key={p.id}>{p.name}</li>
        ))}
      </ul>
    </div>
  );
}

That's basically it.
The key is not "which one is better", but "who is better suited to do what". Only through a reasonable division of labor, allowing Server Components to be responsible for data and content, and Client Components to be responsible for interaction, can the maximum power of React's new architecture be unleashed.

The above is the detailed content of React Server Components vs. Client Components: A Complete Guide. For more information, please follow other related articles on the PHP Chinese website!