React Server Components

React Server Components (RSC) run exclusively on the server. They can access databases, file systems, and secrets directly, but cannot use browser APIs, useState, useEffect, or event handlers. They render to HTML sent to the client without any client-side JavaScript bundle for that component. In architecture discussions: 'make it a Server Component' means reduce client-side JS and move data access to the server.

'use client' is a directive (a string literal at the top of a file) that tells React this component and its imports run in the browser. It creates a client boundary — code in this file can use useState, useEffect, and DOM event handlers. Without it, Next.js 13+ treats files as Server Components by default. In reviews: 'needs use client' means the component has browser-specific behaviour.

Hydration is the process where React takes HTML rendered on the server and attaches JavaScript event listeners to make it interactive in the browser. A hydration mismatch occurs when the server-rendered HTML differs from what React generates client-side — this causes visual glitches and console errors. It's a common issue when using browser-only APIs (like localStorage) in server-rendered components.

One key pattern with RSC is that Server Components fetch data and pass it down as props to Client Components. This keeps the data-fetching logic (including API keys, database queries) on the server — it never appears in the client bundle. A Client Component that calls its own fetch() would expose that logic to the browser. In architecture reviews: 'lift the fetch to the Server Component' is a common recommendation.

RSC-compatible means a library can safely run in a React Server Component — it doesn't use window, document, navigator, or other browser globals. Many older libraries (UI libraries, analytics, browser storage wrappers) are not RSC-compatible. In dependency discussions: 'check if it's RSC-compatible' means verify the library doesn't crash when imported in a server context.