A Next.js App Router product page has 'use client' at the top of page.tsx purely so an Add to Cart button can handle a click, and product data fetched higher up is drilled down through three client components to reach it. Walk through how you restructure this.

## Diagnosing the shape Two symptoms travel together here, and they have one cause. The cause is a boundary placed at the **root** of a subtree to satisfy a **leaf** of it. Once `page.tsx` carries `'use client'`, every module it imports is client code, so the entire page — sections, cards, formatting helpers, the lot — is on the client side of the boundary. The first symptom is prop drilling. Server components can each fetch what they need at the point of use. Client components cannot, so the data has to be fetched once, at the top, and threaded downward through components that do not use it. That is the drilling: it is not a styling preference, it is a forced consequence of the boundary position. The second symptom is that everything on the page is now client code — which is a separate topic, but it is worth naming as evidence when you argue for the change. ## The restructuring, step by step **1. Find the actual reason for the directive.** Here it is one `onClick`. Something needs state, an event handler, or a browser API. That component — and only that component — needs the boundary. **2. Extract that leaf into its own module.** ```tsx // app/products/[id]/add-to-cart-button.tsx 'use client' export function AddToCartButton({ productId }: { productId: string }) { return <button onClick={() => addToCart(productId)}>Add to cart</button> } ``` Note the prop: an id, not the product object. A leaf boundary usually needs far less data than a root boundary was being handed. **3. Delete the directive from the page and render the leaf inline.** ```tsx // app/products/[id]/page.tsx — Server Component again import { AddToCartButton } from './add-to-cart-button' export default async function ProductPage({ params, }: { params: Promise<{ id: string }> }) { const { id } = await params const product = await getProduct(id) return ( <article> <h1>{product.name}</h1> <ProductSpecs productId={id} /> <AddToCartButton productId={id} /> </article> ) } ``` **4. Undo the drilling.** Now that `ProductSpecs` and its siblings are server components again, each can await its own data instead of receiving it as props from the top. The page stops being a data-distribution hub. **5. Invert the wrappers that must wrap.** Some interactive components are containers by nature — an accordion, a tab shell, a drag-and-drop pane. You cannot make those leaves. The move is to give them a `children` prop (or named element props) and pass the server-rendered content in from the server parent: ```tsx // server parent <Accordion title="Specifications"> <ProductSpecs productId={id} /> {/* still server-rendered */} </Accordion> ``` The client `Accordion` never imports `ProductSpecs`; it receives finished output and shows or hides it. This is the single most important structural pattern in the App Router, because it is what stops "this needs to be interactive" from cascading upward through the tree. ## Where judgment comes in Not every extraction is worth it. Three considerations: - **Chattiness of state.** If several sibling leaves share state, extracting each one separately means lifting that state into a shared client component anyway. Then the honest boundary is the smallest component that owns the shared state — with server content passed in as children. - **Cohesion.** Splitting a component into a server half and a client half that always ship together, for one handler, can hurt readability more than it helps. Judge it against how much sits below the boundary. - **Contexts.** If the interactive leaves need a client context, place the provider as low as the consumers allow and pass the rest through as children, rather than at the root of every route. ## How to talk about it in an interview Say the diagnosis first ("the boundary is at the root but the requirement is at a leaf"), then the two moves ("push the directive down; invert wrappers to take children"), then the consequence you actually care about ("data fetching goes back to where it is used, so the drilling disappears"). Candidates who jump straight to "split the button out" without naming *why* the drilling existed usually cannot handle the accordion follow-up.