React
React Server Components: what they are and when to use them
React Server Components run only on the server: their code never reaches the browser and they read data without an API in between.
Key points
- Server Components run on the server and their code never enters the browser bundle.
- The boundary is marked with the use client directive: below it, the component becomes client.
- They do not replace Client Components: they move data and heavy dependencies out of the browser.
“React server components” are components React runs only on the server: their code is never sent to the browser and they can read data directly, without an API in between.
Where the boundary sits
In an application that supports them, every component is a Server Component until you meet the use client directive. From there down, the component and the children it imports become Client Components, with state, effects and event handlers. Props that cross the boundary must be serialisable: functions and classes do not pass.
What changes in the bundle
The code of a Server Component never reaches the browser, so a heavy library used to format dates or render markdown does not weigh on the JavaScript you download. Client Components are still shipped in full. The gain depends on how much code you keep on the server, not on how many components you write.
A project to try them
npx create-next-app@latest rsc-demo --ts --app --no-tailwind
cd rsc-demo
npm run devNext.js, released under the MIT licence, is the reference implementation. The file app/page.tsx is a Server Component by default: make the function async, read a value and return the markup. For a button with state, create a second file with use client at the top and import it.
When to use them
- Pages that read data: a database query inside the component removes the intermediate endpoint and the request waterfall.
- Secrets and API keys: they stay on the server, because the code is not serialised to the browser.
- Heavy dependencies: parsers, formatters and markdown libraries stay out of the bundle when they run on the server.
A live record
In the EneUI catalogue two components show the boundary in practice: chart is a Client Component because it draws and reacts to the mouse, sonner manages notifications with local state. Both are React on Radix primitives under the MIT licence; complete sections are in 1,556 blocks.
The limitation
Server Components are not a feature you switch on in any React project: they need a bundler and a server that implement the protocol. Today the stable path goes through Next.js; integrations with other tools exist but are younger. If your hosting is static only, the model is not available.
Where to continue
The most common mistake is in a Server Component imports a hook; the streaming that goes with them is in streaming and Suspense; the comparison with an island framework is in Astro vs Next.js.
Frequently asked questions
Do Server Components replace Client Components?
No. The two models work together: Server Components read data and produce markup, Client Components handle state, events and effects in the browser.
Can I use hooks in a Server Component?
No. useState, useEffect and the other hooks need a client component. In a Server Component you can use async and await, not hooks.
Do React Server Components work with Vite?
Not with the same support as Next.js. Experimental integrations exist, but the documented and stable path goes through a framework that implements the protocol.
Do Server Components always reduce the JavaScript sent?
No. They reduce only the code of components that stay on the server. A tree of Client Components is shipped in full, even when its parent is a Server Component.
Why does a function prop fail to reach a Client Component?
Because props that cross the boundary must be serialisable. Functions are not, so replace them with Server Actions or declare them inside the client component.