In a React Server Components app, an interactive collapsible panel is a client component and needs to display a server component that queries the database. Why can't the panel import that server component, and what composition pattern lets the server-rendered content appear inside it?

## The rule being enforced `'use client'` marks a module as an entry into the client graph, and everything that module imports goes with it. So the question "can a client component import a server component?" has a mechanical answer: no, because the act of importing would relocate that module to the client, and a module on the client cannot do the things that made it a server component — direct `await` of a data source, use of server-only credentials, shipping zero JavaScript. What is *not* forbidden is a server component appearing **inside** a client component in the rendered tree. Those are two different relationships, and confusing them is the whole point of this interview question: - **import** = a compile-time edge in the module graph. Blocked. - **render as a child** = a runtime edge in the element tree. Fine. ## The pattern: pass elements, not imports The composition happens one level up, in a server component that is allowed to import both sides. ```jsx // Page.jsx — a server component (no directive) import { Panel } from './Panel'; // client component import { UserTable } from './UserTable'; // server component export default function Page() { return ( <Panel title="Users"> <UserTable /> </Panel> ); } ``` ```jsx // Panel.jsx 'use client'; import { useState } from 'react'; export function Panel({ title, children }) { const [open, setOpen] = useState(false); return ( <section> <button onClick={() => setOpen(!open)}>{title}</button> {open && children} </section> ); } ``` `Panel` never names `UserTable`. It declares a hole. The server fills the hole. ## Why this is sound rather than a loophole When React renders `Page` on the server it evaluates `<UserTable />` there — the query runs on the server, the component's code stays on the server — and what it produces is a rendered result. That result is what gets handed to `Panel` as the `children` prop. From the panel's perspective `children` is just an opaque piece of UI: it can render it, hide it, or wrap it in a `<div>`, but it cannot inspect it, call into it, or re-render it. Nothing about `UserTable`'s implementation is needed in the browser, so nothing about it is shipped. A useful consequence: when the panel re-renders because its own state changed, `children` is the same value it was given. The server subtree does not re-run in the browser — there is no browser copy of it to run. ## Any element-typed prop works `children` is the ergonomic default, but there is nothing special about the name. A client component can accept several slots: ```jsx <Layout sidebar={<Nav />} main={<UserTable />} /> ``` As long as the value is an element the server produced, it crosses the boundary the same way. That is the difference candidates should be able to state: an *element* prop is rendered output, whereas naming the component type inside the client module would be an import. ## What this buys you: thin boundaries The reason interviewers like this question is that it is the practical technique for keeping client bundles small. The naive structure puts the interactive shell high in the tree and everything below it becomes client code by inheritance. The slot structure inverts it: the interactive shell is a small wrapper with holes, and the large, data-heavy, dependency-heavy content stays above the line on the server. Same rendered page; a fraction of the JavaScript. The habit to internalise is *pass content down, do not import it down*. When a client component starts wanting to import something substantial, that is the signal to turn the import into a prop. ## The limits worth naming The pattern moves rendered output, so it does not let a client component do anything dynamic with the server child. It cannot decide, at runtime in the browser, to render a *different* server component; the choices had to exist in what the server sent. If the interaction genuinely requires new server-rendered content on demand, that is a fetch or a navigation, not a slot — and the props you pass alongside the slot still have to be values that can cross the boundary at all, which is a separate constraint. ## The one-sentence answer A client component cannot import a server component, because importing it would make it client code — so a server parent renders it and passes it in as `children`, and only the rendered output crosses the boundary.