Server components: what moves to the server, and what shouldn't
A practical rule for deciding which parts of a page stay on the server and which need to be client components.
Hammad Iqbal
Software Engineer
Server components make it easy to fetch data next to the markup that uses it, and they keep large dependencies out of the browser bundle. The confusing part is the boundary. Here is the simple rule I use to decide which side a piece of UI belongs on.
- Default to the server and add a client boundary only where interaction needs it.
- Push the client boundary down to the smallest component that needs state or events.
- Pass plain data across the boundary, not functions or class instances.
Default to the server
Anything that only renders data, such as lists, article bodies, and product details, has no reason to ship JavaScript to the browser. Fetch on the server, render HTML, and send nothing extra.
Draw the client line low
A like button needs state, but the page around it does not. Marking the whole page as a client component to support one button throws away the benefit. Make the button its own small client component and keep the page on the server.
What crosses the boundary
Props passed from a server component to a client one must be serializable. That pushes you toward passing simple data and letting the client component own its handlers, which is usually a cleaner design anyway.
Keep pages on the server, make small client islands for interaction, and pass only plain data between them.
Have a project this kind of thinking applies to?
Tell me what you're building — I read every message myself.