The Diagram That Finally Made It Click
The mental model I was missing: Server Components are not 'components that render on the server instead of the client.' That framing breaks as soon as you ask how they compose with Client Components. The right framing is a rendering tree that has two zones — a server zone where components never touch the browser, and a client zone where interactivity lives.
Server Components flow data down. Client Components own state and events. The boundary between them is where you use 'use client'. Once I drew this as a tree diagram with a clear dotted line, everything else — why you can't use useState in a Server Component, why you can pass Server Components as children to Client Components — became obvious rather than arbitrary.
What This Means for How You Architect Features
The practical payoff is significant. For a data-heavy dashboard, I now default to Server Components for all the data-fetching and structural layout, and only reach for Client Components at the leaves where users actually interact. The result is a dramatically smaller JS bundle and much faster initial render.
The mistake I see most often is sprinkling 'use client' at the top of every file out of habit. Each one of those expands the client bundle. The goal is to push 'use client' as far down the component tree as possible — ideally to a button or an input, not an entire page section.
Key takeaways
- Think of Server Components as a server zone and Client Components as a client zone — the boundary is 'use client', and it should be pushed as far down the tree as possible
- Server Components run once on the server — they can be async, fetch data directly, and never increase your JS bundle size
- You can pass Server Components as children props into Client Components — this is how you compose across the boundary without breaking the mental model
Conclusion
React Server Components are genuinely one of the most architecturally interesting things to happen to React in years. The learning curve is real, but the payoff — smaller bundles, faster pages, simpler data fetching — is worth the investment. Draw the diagram. It helps.
Enjoyed this article?
Vivek Kumar Singh
Technical Expert · Full Stack Cloud Engineer · Tokyo, Japan
