~/brav0kado
← guides
#React#Next.js#Architecture

Understanding React Server Components

A practical walkthrough of RSC patterns, when to use them, and how they change the client/server boundary.

March 10, 2026·8 min read

Introduction

React Server Components (RSC) shift rendering responsibility to the server by default. This isn't just SSR — components stay on the server permanently and never ship JavaScript to the client.

Why it matters

With the Pages Router, every component was a client component. You'd opt into server rendering via getServerSideProps or getStaticProps, but the component code still shipped to the browser. RSC changes the default: components run only on the server unless you explicitly opt in with "use client".

The mental model

Server Components  →  zero JS bundle impact, can fetch directly
Client Components  →  interactive, access hooks, browser APIs

The boundary is one-way: Server Components can import Client Components, but Client Components cannot import Server Components.

When to use each

  • Reads from a database or API
  • Doesn't need useState, useEffect, or event handlers
  • Handles sensitive data (credentials never leave the server)

Push "use client" as deep as possible — ideally to leaf interactive nodes like a button or an input.

Common mistake

Adding "use client" to a layout or page because one child needs interactivity. Instead, extract just the interactive part into its own Client Component.