One component can reuse different layouts at different container widths

What it is

A comment composer in a wide modal: attach, emoji, send in a row. In a right rail: the three stack. That is one component switching inner templates on its own width — not CommentWide and CommentCompact, and not a parent-passed variant="compact" that goes stale. The container narrows; it rearranges.

Container queries supply the ruler. This leaf is the reuse bill: layout variants live inside the component and switch with available width.

Why it happens

A parent-passed variant drifts from real width: drag the split, the rail goes 420 to 280, the parent still thinks regular. A component that asks its own width keeps the template (stack / row, hide meta, icon-only CTA) on the real space. What you reuse is one implementation, not two lookalike codepaths.

Keep the variants few. Two or three inner structures cover most slots; more, and neighbouring cards in an auto-fill grid grow different faces. That is the over-subdivision problem.

Where it stops holding

Genuinely different jobs (an editor versus a read-only citation) should not be jammed into width variants; those are two components. Server render often cannot know container width, so the first paint may flash then switch; pick a default (usually the narrow, non-overflowing one). Mail and PDF with a fixed page width have no “container in motion,” so variants sit idle.

Applying it

• List the inner structures the component needs (row, stack, icon-only), put the switch inside it, and let callers only provide a slot with a width.
• Delete caller size / compact props unless they mean semantics (emphasis), not width.
• How to check: leave the window alone; drag a split or change grid column count. The component should switch templates itself. If it only switches when a parent string changes, reuse is still tied to the caller. Then park two slots on one page and confirm they do not couple — the narrow one stacks while the wide one stays a row.

Related

• Same group: F2.15.1 Container queries respond to a component’s own space, not the viewport · F2.15.3 Component-level response can evolve without the page breakpoint system · F2.15.4 Too many container breakpoints make the component unpredictable
• Nearby: F2.08 Card layout · F2.11 Fluid and adaptive layout · E4.01 Cards
• Search terms: component variants · container query · reuse · split view