Build fluency in the vocabulary of rendering a component on the server with zero client JavaScript.
0 / 5 completed
1 / 5
At standup, a dev mentions a component that renders entirely on the server and ships no component JavaScript to the client bundle at all, reducing how much code the browser has to download. What is this component type called?
A React Server Component renders entirely on the server and ships no component JavaScript to the client bundle at all, reducing how much code the browser has to download for a component that doesn't need any client-side interactivity. A traditional client-rendered component always ships its own JavaScript to the browser, even if it never actually needs to run any logic there. This zero-client-JS footprint is what makes Server Components attractive for reducing an application's overall bundle size.
2 / 5
During a design review, the team wants to explicitly mark which part of the component tree needs interactivity, like a hook or a browser API, distinguishing it from the rest that can stay server-rendered only. Which capability supports this?
The 'use client' boundary explicitly marks which part of the component tree needs interactivity, like a hook or a browser API, distinguishing it from the rest of the tree that can stay server-rendered only and ship no JavaScript. Treating every component identically, with no such boundary, forces the whole tree to ship client JavaScript even where it's genuinely unnecessary. This explicit boundary is what lets a single application mix server-only and interactive client components deliberately.
3 / 5
In a code review, a dev notices a Server Component fetching data directly, like querying a database, without needing a separate client-side fetch call or a loading state managed in the browser. What does this represent?
Direct server-side data fetching inside a Server Component, like querying a database, happens as part of the server's own rendering, with no need for a separate client-side fetch call or a loading state managed in the browser at all. Fetching data only through a separate client-side call, with a browser-managed loading state, is the pattern Server Components are specifically meant to simplify away for data that's needed at render time. This direct, server-side fetch is one of the most practical benefits of moving a data-heavy component to the server.
4 / 5
An incident report shows a build failed because a component using useState and useEffect had been left without a 'use client' boundary, and a Server Component isn't allowed to use a hook that depends on client-side state or lifecycle at all. What practice would prevent this?
Adding a 'use client' boundary to any component that genuinely needs a hook like useState or useEffect keeps it correctly separated into the client-rendered part of the tree, rather than leaving it inside the server-only part where such a hook isn't permitted. Leaving the component without that boundary is exactly what caused the build failure in this incident. This explicit boundary placement is a required step whenever a component actually needs client-side interactivity.
5 / 5
During a PR review, a teammate asks why the team moves a data-fetching-heavy component to a Server Component instead of making every component in the application a Client Component by default. What is the reasoning?
Making every component a Client Component ships unnecessary JavaScript to the browser even for a component with no real interactivity, inflating the bundle a user has to download for no functional benefit. A Server Component ships none of that JavaScript at all and can fetch its data directly on the server, cutting both bundle size and an extra client-side fetch round trip. The tradeoff is the added mental model of correctly identifying and marking exactly which part of the tree genuinely needs a 'use client' boundary.