Why can a React Server Component not call useState or useEffect, or attach an onClick handler to the DOM elements it renders?

## The single underlying fact Every restriction on Server Components follows from one property: **the component runs once, on the server, and then it is over.** It produces a description of UI, that description is sent to the browser, and the function itself is never called again and never exists in the browser at all. Once you hold that firmly, you do not have to memorise a list of banned APIs — you can derive it. ## Why state is meaningless there `useState` is not really "a place to store a value". It is a request for React to (a) remember a value across renders of this particular component instance and (b) re-render that instance when the value changes. Both halves need a live instance. On the server, the render happens once and the output is serialized. There is no persistent instance: the next request creates a fresh render, and in between there is nothing holding a value. And there is nobody to re-render — the browser holds finished output, not a runnable copy of the component. A setter would have nothing to schedule. So `useState`, `useReducer`, and the other state-bearing hooks are unavailable, and React errors out rather than pretending: ```jsx // Server Component — this throws. export default function Counter() { const [n, setN] = useState(0); // error: add 'use client' to use useState return <p>{n}</p>; } ``` ## Why effects have nothing to run against `useEffect` is defined in terms of the commit: React renders, commits the result to the DOM, paints, and *then* runs your effect, later running its cleanup when the component unmounts or dependencies change. A server render produces no DOM and never mounts anything — there is no commit for the effect to come after, and no unmount for cleanup to come before. This is why the answer "the effect just runs on the server instead" is wrong in an instructive way. Effects exist to synchronise a component with something outside React — a subscription, a timer, an imperative widget, a browser API. All of those are *client* concerns with lifetimes. A server render has no lifetime to synchronise with; it has a beginning and an end a few milliseconds apart. The same reasoning excludes `useLayoutEffect`, DOM refs, and anything touching `window` or `document`. ## Why handlers cannot be attached When you write `<button onClick={fn}>` in a Client Component, React registers the handler in the browser and calls your function there. For that to work two things must be true: the function must exist in the browser, and something must be listening. A Server Component's code never ships. There is no function in the browser to call, so an `onClick` written there cannot ever fire. React treats passing a function across the server→client seam as an error rather than silently dropping it, which is the behaviour you want — a handler that silently does nothing is a much worse bug than a build-time failure. ## Context, too A related restriction worth naming: React does not support context in Server Components. Context is a runtime construct maintained by the renderer as it walks a live tree, and the server side of the boundary does not carry one. Pass values down as props from the Server Component, and read context inside Client Components below the boundary. ## What you do instead The move is always the same: identify the smallest piece that genuinely needs the browser and make *that* a Client Component, leaving the surrounding data-fetching and markup on the server. ```jsx // Server Component: no state, no handlers, just data and structure. export default async function Article({ slug }) { const post = await db.posts.bySlug(slug); return ( <article> <h1>{post.title}</h1> <LikeButton postId={post.id} initialLikes={post.likes} /> </article> ); } ``` `LikeButton` is a `'use client'` module holding the count in state and owning the click. The article body — including whatever heavy Markdown or sanitisation library rendered it — stays on the server. ## How to talk about this in an interview Weak answers recite the rule ("hooks don't work in Server Components"). Strong answers derive it: no persistent instance means no state; no commit means no effects; no shipped code means no handlers. Then name the escape hatch — push the interactive leaf into a Client Component — and note that the restriction is enforced loudly rather than silently, which is what makes the model safe to work in.