React Server Components (RSC)
React Server Components render on the server by default, send their result to the client, and keep server-only code — database queries, secrets, heavy dependencies — out of the browser bundle. The result is less JavaScript shipped and data access right where the component lives.
RSC inverts React's default: components are server components unless you opt into the client. You don't typically use RSC in bare React — it's delivered through frameworks like Next.js.
TL;DR
- Components run on the server by default; client interactivity is opt-in.
- Mark interactive components with the
'use client'directive. - Server components can touch the database and secrets; they ship no JS.
- Props crossing the server → client boundary must be serializable.
- RSC is used through a framework, not bare React.
Quick Example
A server component fetches data and hands it to a client component for interactivity:
Core Concepts
Think in boundaries:
- Server components — access server resources (DB, secrets, filesystem), render to a payload, ship no JavaScript. No hooks, no browser APIs, no event handlers.
- Client components — interactive UI with state and effects; they hydrate in the browser and ship JS.
The 'use client' directive marks where the server boundary ends and the client tree begins.
Best Practices
- Keep secrets in server components — never move server-only logic into a client component.
- Push the client boundary down — make pages/layouts server components and isolate
'use client'in small interactive leaves. - Pass only serializable props across the boundary (plain objects, arrays, primitives) — not functions or class instances.
Common Mistakes
Passing non-serializable props across the boundary
Marking the whole tree 'use client'
FAQ
How is RSC different from SSR?
SSR renders components (including client ones) to HTML for the initial request, then hydrates them in the browser. RSC components render to a payload and ship no client JavaScript at all. They're complementary: RSC reduces bundle size; SSR produces the initial HTML.
What can't server components do?
They can't use state or effects (useState, useEffect), event handlers, or browser APIs — anything interactive. Those belong in client components marked 'use client'.
When should I add 'use client'?
Only when a component needs interactivity: state, effects, event handlers, or browser-only APIs. Everything else should stay a server component to keep the bundle small.
Do I need a framework to use RSC?
In practice, yes. RSC requires a bundler/runtime integration to handle the server/client boundary and streaming. Next.js (App Router) is the main production implementation today.
Related Topics
- Next.js — The primary RSC implementation
- React — The underlying library
- SEO for SPAs — Why server rendering helps
- Web Performance — Shipping less JavaScript