Understanding React Server Components: Concepts, Usage, and Implementation

As front‑end responsibilities grow, codebases—especially React applications—become large, creating challenges for client‑side bundle size and server‑side rendering (SSR). React Server Components (RSC) are introduced by the React team to address these issues by allowing components that run exclusively on the server.

1. Getting Started

Official resources include the blog post Introducing Zero‑Bundle‑Size React Server Components , a full‑stack demo repository, the RFC, and a subtitled video explaining the feature.

2. Basic Concepts

Component Types

• Server component : cannot use client‑only APIs (DOM, useState, useEffect). • Client component : regular React component that runs in the browser. • Shared component : can be used as either server or client component depending on the importer.

Naming Convention

Server components use .server.js , client components use .client.js , and shared components use the normal .js extension.

Component References

The only restriction is that a client component may not directly import a server component; otherwise, components may reference each other freely.

3. Runtime Mechanism

The official demo shows a sidebar with red (server) and green (client) components. When a server component renders a client component, the server emits a JSON description (M‑id) for the client component and a rendered tree (J‑id) for the server component. The client later resolves the placeholders and completes the UI.

Simple Example

// Test.client.js
export default function Test({text}) {
  return
{text}
}

// App.server.js
import Test from "./Test.client"
export default function App() {
  return (
)
}

The server response contains an M‑id describing the client component and a J‑id representing the rendered server tree, with placeholders (e.g., @1 ) linking them.

Using Server Components Inside Client Components

Server components can be passed as JSX props to client components; the JSX is rendered on the server and sent to the client, allowing a client component to “contain” a server component without direct import.

4. Streaming Protocol

When a server‑side request is blocked, React can stream partial HTML to the client, displaying skeletons while waiting for the blocked component. This is achieved using Suspense and tags that the client later fills.

// Delay.server.js
export default function Delay() {
  fetch('http://localhost:4000/sleep/5000');
  return
I am delay
}

// App.server.js
import Delay from "./Delay.server"
export default function App() {
  return (
)
}

Streaming produces chunks where placeholders (e.g., @2 ) are later replaced once the delayed component resolves.

5. Motivation & Design Goals

Zero‑bundle‑size for server components.

Full server‑side API access.

Automatic code‑splitting of client components.

Eliminate client‑server waterfalls.

Reduce abstraction tax by rendering on the server.

Provide a unified solution for “thin” vs. “fat” client debates.

6. Relation to Existing Technologies

RSC complements SSR, can be used together, and offers progressive rendering via streaming. Compared to GraphQL, RSC provides a React‑native way to reduce round‑trips without requiring a separate query language. It also resembles JSP/ASP in server‑side templating but supports partial updates and client‑side state preservation.

7. Future Outlook

Graceful degradation to pure client rendering under high server load.

Further best‑practice guidance to identify suitable scenarios.

8. Conclusion

React Server Components represent an experimental yet promising approach to shift part of the rendering workload to the server, reduce JavaScript bundle size, and enable progressive streaming. While still maturing, they open new possibilities for modern front‑end architectures.