Why can a component return several sibling elements without a wrapper, and what is rendered when it returns nothing?

Two small mechanisms come from the same requirement: a component returns a description, and a description does not have to correspond one-to-one with host nodes. ## Why a wrapper is not free The obvious way to return three siblings is to wrap them in one container element. That works, and often it is wrong, because the host's rules care about direct parentage: - layout containers style and position their **direct** children, so an extra element in between silently changes the layout; - some host structures accept only specific children, so a wrapper is not merely ugly but invalid; - selectors written against the expected structure stop matching; - every extra node costs memory, traversal and a line in the accessibility tree, and deeply reusable components multiply the effect. A fragment solves this by being a grouping construct in the description only. Templates usually offer a wrapper-less grouping element or simply allow multiple roots; render functions return an array or the framework's grouping node. The runtime renders the children where the fragment sat and creates nothing for the fragment itself. ## How the runtime finds the group again Since the fragment has no host node, the runtime needs another way to know where the group's children begin and end when the output later changes. Implementations typically keep that information internally — a record of the child range, sometimes an invisible marker node in the host tree acting as an anchor. The practical consequences for an author are worth knowing: - you cannot attach a style, a listener or a reference to the fragment itself; there is nothing to attach it to; - if the group's children are generated from a collection, each child still needs its own identity for the runtime to match them across updates, exactly as any list does; - a fragment can usually carry only bookkeeping such as that identity, not attributes. ## Rendering nothing A component that describes no output renders nothing. Frameworks express this as returning an empty value or a fragment with no children, and it is the normal way to write a component whose work is conditional: a banner with no message to show, a permission-gated control, a placeholder that has nothing to hold. The important distinction is between **describing nothing** and **not existing**: | | describes no output | removed from the description by a parent | |---|---|---| | component instance | alive | destroyed | | its state | kept | discarded | | its effects | still running | cleanup has run | | host nodes | none | none | | next update | can describe output again | a fresh instance, from initial state | Both show the same empty screen, which is why the difference is easy to miss and worth saying out loud. A component that renders nothing while it waits for data still owns that in-flight request; one whose parent stopped describing it does not. ## Where empty output is the wrong tool Two habits to avoid. First, using empty output to *hide* something that should stop working: the instance and its effects live on, so a poller or a subscription inside keeps running exactly as it did while visible. If work must stop, the parent should stop describing the component. Second, returning nothing where the caller needs structure: a component that sometimes yields no nodes can collapse a layout that assumed a child was there, and a grid with a variable number of children can shift. Neither is a bug in the framework — it is a contract the component should state, ideally in its documentation: consumers need to know whether a component can yield no nodes, because a layout built around it may depend on one being there. ## Interview shape Name the fragment as a description-only grouping node and give one concrete reason a wrapper hurts — the direct-child layout relationship is the most convincing, because it is visible and unambiguous. Then say that rendering nothing is legitimate and that the instance survives it. If asked to go further, note that the runtime still tracks the group's extent even without a node for it, and that children generated from a collection need their own identities regardless of the fragment.