Pass server-fetched data from Server Components to nested Client Components

WHAT THIS TESTS: The interviewer is probing your mental model of the React Server Component boundary in Next.js App Router. Specifically, they want to know if you understand that Server Components execute exclusively on the server, cannot use client-side hooks or browser APIs, and must communicate with Client Components through serializable props. The question also surfaces whether you know that React Context is unavailable in Server Components and that data fetching should happen as close to the source as possible.

A GOOD ANSWER COVERS: First, state that Server Components can be async and fetch data directly during render, eliminating the need for useEffect or client-side data fetching libraries. Second, explain that the fetched data must be passed as props to Client Components because props are the only channel across the server-client boundary. Third, mention that the data must be serializable, meaning functions, class instances, or non-JSON values cannot cross this boundary. Fourth, acknowledge that if many nested Client Components need the same data, you can use prop drilling or wrap a Client Component around a subtree and pass data via props to that wrapper, but you cannot create a React Context in a Server Component and consume it inside a Client Component. Fifth, note that the Server Component itself remains non-interactive while the Client Component handles state, effects, and event handlers.

COMMON WRONG ANSWERS: A major red flag is suggesting the use of useState, useEffect, or useContext inside the Server Component to fetch or share data. Another mistake is proposing to fetch inside the Client Component with useEffect when the data is needed at page load and is not user-specific or dynamic after hydration. Some candidates incorrectly suggest lifting state into a global store or URL query parameters as the primary pattern, missing the simplicity of server-side fetching and prop passing. Finally, claiming that Context can be used across the server-client boundary shows a fundamental misunderstanding of how RSC payloads work.

LIKELY FOLLOW-UPS: The interviewer may ask how you would refetch or mutate data after the initial server render, which leads to Server Actions or API routes combined with optimistic UI. They might probe what happens if the prop tree is deeply nested, pushing you toward composition patterns where a single Client Component wrapper receives server data and distributes it internally via Context to its own client subtree. They could also ask about caching implications, such as how fetch deduplication works in Server Components or how to control the cache lifetime with revalidatePath or cache tags.

ONE CONCRETE EXAMPLE: Imagine a product detail page that is a Server Component. It fetches product metadata from a CMS using an async database call during render. The page then renders an AddToCartButton, which is a Client Component marked with the use client directive. The Server Component passes the productId, price, and inventory count as props to AddToCartButton. The button uses useState to manage hover styles and an onClick handler that calls a Server Action to add the item to the cart. The Server Component never imports useState, and the Client Component never fetches the initial product data.