You maintain a design-system library of custom elements. How do you decide what a component exposes as a named <slot> versus what it renders itself, and what does publishing a slot name commit you to?

## The question behind the question Every reusable component draws a line between what it guarantees and what the caller supplies. Slots are the platform's mechanism for that line, and the interview is really asking whether you can place the line deliberately rather than by habit. ## Slot it when the caller must own it Good candidates for a named slot: - **Arbitrary rich content** — a card body, a dialog description. You cannot enumerate the markup, so trying to accept it as a string means either escaping it (limited) or injecting it (an XSS sink you have just created for every consumer). - **Caller-supplied interactive elements** — the action buttons in a dialog footer, where the caller owns the handlers, labels and disabled states. - **Optional decoration with a sensible default** — an icon region whose `<slot name="icon">` carries fallback content that renders until someone overrides it. ## Render it yourself when you are accountable for it Keep inside the component anything whose correctness you are promising: - The wrapper structure and layout, so spacing and responsive behaviour cannot be broken from outside. - Accessibility wiring — the element that carries the role, the relationships between the labelled region and the content. If the caller supplies the node that must be referenced, you cannot guarantee the relationship holds, because you cannot rewrite what you are handed. - Anything with invariants: exactly one close button, a live region that must exist, ordering that the component's keyboard handling depends on. The test that settles most cases: *if a consumer supplies something wrong here, whose bug is it?* If the answer is "mine", do not slot it. ## What publishing a slot name commits you to A slot name is a public string that lives in consumer markup, and the coupling is loose in the worst way: - **Renames fail silently.** Change `slot="title"` to `slot="heading"` and every existing consumer's title simply stops rendering. No exception, no console message, the element still sits in the DOM. Treat renames as breaking changes, and if you must migrate, keep both slots for a release and warn in development. - **Removing a slot is equally silent** from the caller's side. - **Adding a slot is safe**, which makes additive evolution the cheap direction. - **Fallback content is part of the contract too.** Callers come to rely on the default icon or the empty-state text; changing it changes rendered output for people who supplied nothing. Because of this, the named-slot surface deserves the same discipline as a public function signature: documented, versioned, and kept small. A component with nine named slots is usually a layout configuration language in disguise — a sign the component should be split, or that the caller should be composing smaller elements themselves. ## The limits you are accepting Slots place content; they do not process it. Concretely, the component cannot: - **validate** what it received — it can only inspect `assignedElements()` after the fact and complain; - **transform or wrap** it, the way a render-time library can clone a child and inject props; - **reorder** it — rendering follows document order within a slot; - **fully style** it, since slotted nodes remain the page's nodes and inherit the page's rules. If your design depends on any of those, the content probably wants to be data on a property rather than markup in a slot: an array of options a component renders itself keeps every invariant under your control, at the cost of the flexibility that made slots attractive. ## Two techniques worth having in the answer **A development-time audit.** Because unmatched content is invisible rather than loud, add a guard behind a dev flag: ```js for (const child of this.children) { if (!child.assignedSlot) console.warn('[my-card] unslotted child', child); } ``` Run it from the slot's `slotchange` handler. It converts your API's worst failure mode from "nothing renders and nobody knows why" into a message. **Imperative assignment for dynamic routing.** With `attachShadow({ mode: 'open', slotAssignment: 'manual' })`, name matching is switched off and the component calls `slot.assign(node, ...)` itself, choosing at runtime which light children go where. It buys real flexibility — routing by element type, filtering, conditional placement — at the cost of a component that no longer works from markup alone, and it needs a reasonably modern browser (available across the major engines from roughly 2022 onward). It is a good answer for a virtualised or heavily dynamic component and a poor default for a design system, where declarative markup is most of the appeal. ## The summary to say out loud "Slots invert control, and inversion has a price. I slot what the caller must own and keep what I am accountable for. Every name I publish is a permanent, silently-breakable contract, so I keep the set small, ship fallbacks, warn on unslotted children in development, and reach for a data property whenever I need to validate or transform rather than merely place."