React Server Components: Vocabulary for Modern Frontend Development

React Server Components (RSC) introduced a new mental model — and a new vocabulary — for frontend architecture. Whether you are interviewing for a senior frontend role, reviewing a Next.js PR, or explaining the rendering strategy to a backend colleague, precise RSC terminology demonstrates mastery of modern React.

---

The Component Model

Server Component A React component that renders exclusively on the server. It has direct access to databases, file systems, and environment variables. It cannot use hooks like useState or useEffect, and it cannot handle browser events. Server Components are the default in Next.js App Router. Phrase: “The product listing is a Server Component — it fetches data directly from the database without exposing credentials to the client.”

Client Component A component that can use browser APIs, React hooks, and event handlers. Marked with the 'use client' directive at the top of the file. Client Components can be rendered on the server too (for the initial HTML), but they are hydrated on the client. Phrase: “The search bar is a Client Component because it needs useState to manage the input value.”

‘use client’ directive The string 'use client' at the top of a file that marks the component (and everything it imports) as client-side code. Phrase: “Adding ‘use client’ to the modal component pulled in a large animation library — check the bundle size.”

‘use server’ directive Marks a function as a Server Action — a server-side function that can be called directly from Client Components, typically for form submissions or mutations. Phrase: “The form uses a Server Action marked with ‘use server’ — no API route needed.”

---

Rendering and Delivery

Hydration The process by which React attaches event listeners and state to the static HTML sent by the server, making it interactive in the browser. Hydration is a cost — it requires downloading and executing JavaScript. Phrase: “Excessive hydration was slowing Time to Interactive — we converted several components to Server Components.”

Streaming SSR Server-side rendering that sends HTML to the browser in chunks rather than waiting for the full page to be ready. Suspense boundaries control which parts stream first. Phrase: “With streaming SSR, the shell of the page arrives in milliseconds and the data-heavy sections stream in as they resolve.”

Suspense boundary A React component (<Suspense fallback={<Loading />}>) that defines what to show while a child component’s data or code is still loading. In RSC, Suspense boundaries also define streaming chunks. Phrase: “Wrap the recommendation panel in a Suspense boundary so it doesn’t block the rest of the page from rendering.”

RSC payload The serialised description of the server-rendered component tree sent from the server to the client. The client uses the RSC payload to reconcile the component tree without a full page reload during navigation. Phrase: “The RSC payload for this route is too large — you’re sending too much data that could be filtered on the server.”

---

Data Fetching

Data fetching on server In RSC, components can be async functions that await data directly — no useEffect, no loading states in component code, no client-side fetch calls. Phrase: “The dashboard components are all async Server Components — they fetch their own data at render time.”

Server Action A server-side async function that can be invoked from the client, typically used for mutations (form submissions, database writes). Server Actions replace many use cases for API routes. Phrase: “We replaced the /api/update-profile route with a Server Action — less code, same security boundary.”

---

Interview Phrases You Should Know

• “RSC shifts the data-fetching boundary from the client to the server, reducing JavaScript sent to the browser.”
• “The key trade-off is interactivity — Server Components can’t hold state, so interactive UI must be Client Components.”
• “Hydration cost is why converting static UI to Server Components improves Core Web Vitals.”
• “Suspense boundaries let you progressively render the page — critical content first, slower data-dependent sections after.”

Practice: Take a Next.js App Router page you have built and write a 100-word architectural explanation of which components are Server Components and why, using the vocabulary from this post.

Expanding Your Understanding: Common Communication Challenges

Let’s be honest – even experienced developers sometimes struggle with the rapid evolution of frontend terminology. For non-native English speakers, navigating these new concepts in React Server Components (RSCs) can feel particularly challenging. It’s not just about understanding what they mean; it’s also about how they’re used in conversations and documentation – the specific phrasing and expectations around them. A critical part of mastering this vocabulary is recognizing subtle differences in emphasis, levels of formality, and the nuances that can lead to misunderstandings.

One frequent issue arises during code reviews. Imagine receiving a comment like: “This RSC should fully hydrate before rendering the UI.” While technically correct – referring to the process of bringing an initially server-rendered component to its interactive state on the client – it can sound demanding and perhaps even accusatory. A more constructive phrasing might be, “Let’s ensure this RSC is prepared for a smooth transition to client-side interactivity; perhaps exploring strategies for optimized hydration could improve performance.” The original comment implies blame; the revised one focuses on collaboration and improvement. Similarly, Slack messages discussing architectural choices can quickly become complex. “We need to implement streaming SSR to reduce initial load times” might be misinterpreted as a technical directive without an explanation of why that specific approach is being favored – perhaps it’s tied to a particular deployment strategy or client device profile.

Another area where confusion arises is around the distinction between “server” and “client.” Developers often use “the server” casually, but in the context of RSCs, referring to the component as a server component is more precise. Describing a PR like this: “This PR refactors the data fetching logic within the server component to improve performance” is clearer than simply saying “this PR improves data fetching.” The former immediately establishes the scope and purpose of the change. It’s about communicating where the work is happening, not just what it’s doing.

Finally, remember that technical jargon isn’t always universally understood. Always strive for clarity when explaining your reasoning – even if you have to break down complex concepts into simpler terms. Don’t be afraid to ask clarifying questions; it’s far better to seek understanding than to make assumptions.

# Example CLI command (using Vite) demonstrating a simple RSC setup:
npm create vite@latest my-rsc --template react-ts
cd my-rsc
npm install  # Installs dependencies