Composition, Slots & Reuse

## What a default content slot is Most of a component's markup is fixed: it describes the structure that component always renders. A **default content slot** is the one position in that markup where the framework renders something the component did not write — whatever the caller placed between the component's opening and closing tags. The component ships a frame; the caller ships what goes in it. This is **content projection**, and the unlabelled region that takes the caller's content with no further naming is the **default** slot. The difference from an ordinary input is what travels. An input carries **data**: a string, a number, an object. A slot carries **markup**: a live subtree with its own elements, child components, bindings and event handlers, created and updated by the framework. ## Who owns projected content - **The caller declares it**, so every name inside it resolves in the caller's scope — the caller's state, the caller's handlers, the caller's components. The receiving component cannot rebind those names. - **The caller's data drives it.** When the caller's state changes, the projected markup updates, even though it renders inside someone else's frame. - **Its identity is stable.** When the receiving component re-renders, the projected subtree is the same subtree as before rather than a fresh copy, so anything stateful inside it keeps its state. - **The receiving component has no portable way to read inside it.** Some runtimes expose a list of projected entries, but inspecting or rewriting them couples the component to markup it does not own; treat the content as opaque. ## What the receiving component still decides 1. **Placement** — where in its own structure the content appears. 2. **Chrome** — the border, padding, heading, ARIA roles and landmarks it wraps around the content. 3. **Whether it renders at all** — the slot can sit inside a conditional, a disclosure, an inactive tab. 4. **What to show instead** — **fallback content**, rendered when the caller passed nothing. Whether the same slot may be rendered in more than one place, or more than once, differs by runtime: treat that as a per-runtime rule rather than an assumption, and when you genuinely need the content more than once, take it as a parameterised block instead. ## Containment versus specialization | | Containment (projection) | Specialization (fixed inputs) | |---|---|---| | What varies per caller | the markup supplied | the values supplied | | What the component knows | where content goes | what the content means | | Public surface | slot names | input names | | Fits | frames: card, dialog, panel, page layout | roles: money field, avatar, status badge | | Fails when | the caller needs the component's own data | every new case adds another boolean | Both are composition; they differ in which side owns the markup. A dialog that takes a title region, a body region and a footer region is containment — it has no opinion about what a footer contains. A confirmation dialog built on that dialog, with a fixed title, a message input and two buttons, is specialization: it has an opinion, and it expresses that opinion by **using** the generic dialog, not by inheriting from it. ## Why projection replaced inheriting from a base component - Subclassing a component to inject markup requires knowing its internal structure, and that structure changes. - A base component that must anticipate every subclass grows extension points nobody else needs — the fragile base class problem in component form. - A slot makes the extension point **named and narrow**: the only promise is that content you give me renders here. - The component's public surface stays the same three things — inputs, outputs, slot names — for every consumer. The other tempting shortcut is an input carrying pre-rendered markup as a string. That forces the receiving component to insert raw markup the framework cannot track: no bindings, no handlers, no child components, no teardown, and an injection hazard for anything a user typed. Projected content avoids all of it because the framework created the subtree in the first place. ## Where runtimes differ Frameworks agree on the ownership rule and differ in mechanics. A runtime that re-runs a component function on every state write hands the already-created content in as a value the component positions. A runtime with fine-grained tracking compiles the projected region into its own reactive block that stays attached to the caller. A compile-time runtime resolves slots when it builds the component, so an unfilled slot can be eliminated outright. None of that changes the contract: the caller writes the content, and the component decides where it lands.