Skip to content
Vercel9 min read

A mental model for React Server Components

How to think about the boundary between server and client without resorting to rules of thumb that break the moment your app grows.

RSCReact

Server Components flipped the contract: instead of "everything is a client component, with server data fetched alongside", we now have a default of server-rendered output that can opt back into the client where interaction is required. The mental shift takes a week. The mental model takes a quarter.

What runs where

Server Components run once, on the server, and never re-render in the browser. Client Components run on both. Anything you import from a server component into a client component crosses the network boundary — which is exactly the moment to start asking serialization questions.

Three rules that survived contact with reality

  1. Default everything to a Server Component until you need state or effects.
  2. The smallest "use client" file is almost always the right one.
  3. Treat the server/client boundary like an HTTP boundary — because it is.

If you take one thing from this article: stop thinking of RSC as "an optimization". It's a different shape of program.

Comments(3)

Sign in to join the conversation.
  1. Sam Patel

    The 'smallest "use client" file' rule alone has saved me hours. Migrated three pages this morning.

    1. Maya Chen

      Same. The hardest part was un-learning the 'wrap everything in a provider' habit from the SPA days.

  2. Devon Liu

    Curious how you're handling pages that are 90% interactive — it feels like RSC adds overhead there with no clear win.