In a telecom app's design system, a plan card that works full-width on phones breaks in a desktop sidebar despite page overrides; what component rule fixes this?

seniorshould knowfreq 38%

answer

wrong question: window or me?
wide window, narrow slot
templates own window classes
spec layouts by own width
test at slot widths, not devices

basics

~20 s

Make the card respond to the width of the slot it sits in, not to the window's breakpoint. Page templates respond to window-width classes; each component's spec defines its layouts by its own available width, so it works in any placement without overrides.

solid answer

~50 s

The card fails because it asks how wide the window is, when its layout depends only on how wide its own slot is: in a desktop sidebar the window is expanded, so the card picks its row layout, but the slot is narrow. The rule is a split of responsibility: the app shell and page templates respond to window-width classes, reusable components respond to their own available width, and simple atoms just stretch. The card's spec then lists its layouts by own-width range, derives the thresholds from realistic content and states a minimum width. Every platform can express this: web components can respond to an ancestor's size, and native views measure the bounds they are laid out into. To migrate, inventory the overrides, use each as a test case, ship the slot-responsive card, delete overrides placement by placement, and test the component at slot widths rather than window sizes.

The card fails because it asks how wide the **window** is, when its layout depends only on how wide **its own slot** is: in a desktop sidebar the window is `expanded`, so the card picks its row layout, but the slot is narrow. The rule is a split of responsibility: the **app shell and page templates respond to window-width classes**, **reusable components respond to their own available width**, and simple atoms just stretch. The card's spec then lists its layouts by own-width range, derives the thresholds from realistic content and states a minimum width. Every platform can express this: web components can respond to an ancestor's size, and native views measure the bounds they are laid out into. To migrate, inventory the overrides, use each as a test case, ship the slot-responsive card, delete overrides placement by placement, and test the component at slot widths rather than window sizes.

code

pseudocode · 13 lines

pseudocode

component PlanCard
    MIN_WIDTH = 240        // narrowest slot the spec supports
    ROW_THRESHOLD = 440    // widest point where longest plan name + promo price still wrap badly

    layoutFor(ownWidth):   // ownWidth = width of the slot the card was laid out into
        if ownWidth < MIN_WIDTH:
            warnInDevelopment("PlanCard placed in a slot narrower than its minimum")
            return STACKED
        if ownWidth < ROW_THRESHOLD:
            return STACKED  // price above features, full-width button
        return ROW          // price | features | button

    // never reads the window-width class

go deeper

for a junior

Recall that a reusable component should look at the space it is given, while page templates follow the window's width classes.

for a middle

Explain why a window-keyed component breaks in a narrow slot on a wide window, and what its spec must state about its own width ranges.

for a senior

Show the migration: inventory overrides, turn them into test cases, ship the slot-responsive component, remove overrides and test at slot widths.

for a principal

Decide which components earn slot-responsive behaviour and which stay simple, and how the system keeps templates and components from both owning one layout decision.

Diagnosing the failure

The plan card in a telecom self-service app has two layouts: a stacked one (price above features, a full-width button) and a row one (price, features and button side by side). It was built to pick its layout from the window's width class: compact windows get stacked, larger windows get the row.

That works while the card is always as wide as the page. It breaks when a desktop page places the card in a narrow sidebar beside the account summary: the window is expanded, so the card chooses the row layout, but its own slot is a fraction of that width, so prices wrap and the button is squeezed. Each team patches it with a page-specific override, and the library quietly gains as many hidden variants of the card as it has placements.

The root cause is that the card asks the wrong question: "how wide is the window?" instead of "how wide am I?".

The rule: components respond to their slot

A design system fixes this with an explicit division of responsibility.

Layer	Responds to	Examples
App shell and page templates	Named window-width classes	bottom bar vs rail vs panel, one pane vs two, template column count
Reusable components	Their own available width	plan card, usage summary, comparison table
Simple atoms	Nothing; they stretch or keep a natural size	button, icon, badge

The rule reads: templates decide how much space each slot gets; components decide what to do with the space they are given. A component that follows it works in any slot on any window, and a new placement needs no override.

The model is the same on every platform. On the web, a component can respond to the size of an ancestor container; on native platforms, a view measures the bounds it was laid out into and chooses its arrangement from them.

What the component spec must say

Its layouts and their width ranges, stated against the component's own width: stacked below one threshold, row above it.
Where those thresholds come from: the widths at which realistic content, such as the longest plan name and a price with a promotional note, stops fitting.
A minimum supported width, so template authors know which slots are too small for it.
What never changes across layouts: for example, that the button's label is never truncated.

Migrating a library that already has overrides

Inventory the overrides. Search the consuming apps for page-specific styling or options applied to the card; each one is evidence of a placement the card did not handle.
Define the layouts by own width, using the overrides as test cases: each placement's slot width should land in a range whose layout looks right.
Ship the slot-responsive card with release notes that name the removed window-based behaviour.
Remove overrides placement by placement, confirming each page visually.
Test at slot widths, not window sizes. The component's visual tests render it just below and above each threshold and at its minimum, independently of any page.

Limits and trade-offs

Not every component needs it. Buttons, icons and simple inputs stretch or keep their size; giving them thresholds adds cost without benefit.
The slot's width must not depend on the component. If a container sized itself from its content while the content chose its layout from the container, the result would be circular. Platforms that support this model require the container's width to be settled first, so templates must give slots definite widths.
One source per decision. A card that reads the window class for one property and its own width for another behaves unpredictably; each decision should have one input.
Nesting needs a clear reference. A card in a list in a pane responds to its nearest measured slot, which is the point, but the spec should say which slot that is.
An explicit layout option is a legitimate fallback where a platform cannot measure a slot, but the page then carries layout knowledge again, so it should be the exception rather than the rule.

## Diagnosing the failure The plan card in a telecom self-service app has two layouts: a **stacked** one (price above features, a full-width button) and a **row** one (price, features and button side by side). It was built to pick its layout from the **window's** width class: compact windows get stacked, larger windows get the row. That works while the card is always as wide as the page. It breaks when a desktop page places the card in a narrow **sidebar** beside the account summary: the window is `expanded`, so the card chooses the row layout, but its own slot is a fraction of that width, so prices wrap and the button is squeezed. Each team patches it with a page-specific override, and the library quietly gains as many hidden variants of the card as it has placements. The root cause is that the card asks the wrong question: *"how wide is the window?"* instead of *"how wide am I?"*. ## The rule: components respond to their slot A design system fixes this with an explicit division of responsibility. | Layer | Responds to | Examples | |---|---|---| | App shell and page templates | Named window-width classes | bottom bar vs rail vs panel, one pane vs two, template column count | | Reusable components | Their own available width | plan card, usage summary, comparison table | | Simple atoms | Nothing; they stretch or keep a natural size | button, icon, badge | The rule reads: **templates decide how much space each slot gets; components decide what to do with the space they are given.** A component that follows it works in any slot on any window, and a new placement needs no override. The model is the same on every platform. On the web, a component can respond to the size of an ancestor container; on native platforms, a view measures the bounds it was laid out into and chooses its arrangement from them. ## What the component spec must say 1. **Its layouts and their width ranges**, stated against the component's own width: stacked below one threshold, row above it. 2. **Where those thresholds come from**: the widths at which realistic content, such as the longest plan name and a price with a promotional note, stops fitting. 3. **A minimum supported width**, so template authors know which slots are too small for it. 4. **What never changes across layouts**: for example, that the button's label is never truncated. ## Migrating a library that already has overrides 1. **Inventory the overrides.** Search the consuming apps for page-specific styling or options applied to the card; each one is evidence of a placement the card did not handle. 2. **Define the layouts by own width**, using the overrides as test cases: each placement's slot width should land in a range whose layout looks right. 3. **Ship the slot-responsive card** with release notes that name the removed window-based behaviour. 4. **Remove overrides placement by placement**, confirming each page visually. 5. **Test at slot widths, not window sizes.** The component's visual tests render it just below and above each threshold and at its minimum, independently of any page. ## Limits and trade-offs - **Not every component needs it.** Buttons, icons and simple inputs stretch or keep their size; giving them thresholds adds cost without benefit. - **The slot's width must not depend on the component.** If a container sized itself from its content while the content chose its layout from the container, the result would be circular. Platforms that support this model require the container's width to be settled first, so templates must give slots definite widths. - **One source per decision.** A card that reads the window class for one property and its own width for another behaves unpredictably; each decision should have one input. - **Nesting needs a clear reference.** A card in a list in a pane responds to its nearest measured slot, which is the point, but the spec should say which slot that is. - **An explicit layout option is a legitimate fallback** where a platform cannot measure a slot, but the page then carries layout knowledge again, so it should be the exception rather than the rule.

Why can't the slot size itself from the card while the card chooses its layout from the slot?
That is circular: the card's layout would depend on the slot's width, and the slot's width on the card's layout. Platforms that support this model require the container's width to be settled independently of the child first. So templates must give slots definite widths, from the grid or pane layout, before components inside them choose their arrangement.
Isn't passing a compact option from each page simpler than a slot-responsive component?
It is simpler to build and a reasonable fallback where a platform cannot measure a slot. But it puts layout knowledge back on every page: each new placement must remember the right option, and nothing updates it when a template's slot widths change. Slot-responsive components remove that coupling, which is why they should be the default rule.

saying these in an interview costs you the question

The fix is another override for the sidebar page.
A reusable component should read the window's breakpoint to choose its layout.
Once components respond to their slot, window-width classes are no longer needed.
Every component in the library needs its own width thresholds.
Visual tests at one phone, tablet and desktop window prove the card works everywhere.

In a telecom app's design system, a plan card that works full-width on phones breaks in a desktop sidebar despite page overrides; what component rule fixes this?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Diagnosing the failure

The rule: components respond to their slot

What the component spec must say

Migrating a library that already has overrides

Limits and trade-offs

▾common follow-ups2 questions

▾red flags5 flags

Diagnosing the failure

The rule: components respond to their slot

What the component spec must say

Migrating a library that already has overrides

Limits and trade-offs

answer

go deeper