A Simple Mental Model for React Server Components

Server Components confuse people because they change where code runs. The simplest way I have found to think about them: components are server-side by default, and you opt into the browser only when you need it.

Server by default

A server component can read from a database or the filesystem directly and send finished HTML. Its code never ships to the user, which keeps bundles small.

Client when interactive

If a component needs state, effects, or browser events, mark it as a client component. Push these to the leaves of the tree, such as a button or a form field, so the rest stays on the server.

Mutations with server actions

Forms can call server functions directly. That removes a layer of hand-written API routes for many simple cases, though validation and authorization are still your job.

Common mistakes

• Marking a whole page as client because one child needs state.
• Forgetting that data passed from server to client must be serializable.
• Assuming a server action is private. Treat it like a public endpoint and check permissions inside it.