In a component workshop, how do you decide which examples a component needs, and why keep named examples rather than one playground with property controls?
answer
- start from the spec's list
- variants times meaningful states
- extreme data earns an example
- controls explore, examples record
- an unseen state goes untested
basics
~10 sStart from the component's specified variants and states, add extreme data and setup-dependent states, and skip redundant combinations. Named examples are reviewable, linkable and reusable; states reachable only through controls are rarely seen.
solid answer
~50 sDerive the example set from the component's **spec**: one example per variant and per meaningful state, plus **extreme data** (a very long pet name, a missing photo, no phone number) and states that need setup, such as an open menu or a failed load. Do not write the full cross-product; add a combination only where parts interact — a cancelled video consult may differ from a cancelled clinic visit, while every size of it does not need its own error example. Keep them as **named examples** because each is a durable record: it can be reviewed in a change, linked from a ticket, reused by tests and design review, and compared over time. A single playground with **property controls** is good for exploring *what if*, but states that only exist behind a combination of controls are the ones nobody clicks, so they go unseen and untested. Controls complement the named set.
go deeper
Recall the rule of thumb: one named example per specified variant and state, plus extreme data such as long text and missing fields.
Explain why named examples are the catalog of record, where property controls help, and how to choose combinations without writing the full cross-product.
Show how you would audit a library's workshop against its specs, close gaps, and keep example sets from sprawling as components grow.
Set the standard for what every component's example set must include, and how it ties specs, workshop and tests into one checked list.
## Two ways to exercise a component A component workshop can present a component in two ways: - **Named examples** — fixed renderings with specific inputs and data, each with a name such as *appointment card, cancelled video consult*. - **A playground with property controls** — one rendering whose inputs a viewer changes live through generated controls: text fields, toggles, dropdowns for each input. Both are useful. The question is which one is the **catalog of record**: the thing that says *these are the states this component has, and this is what each looks like*. ## Why named examples are the record - **Reviewable.** A change to the component shows up as changes to specific examples a reviewer can open. - **Linkable.** A bug report, a design review or a support ticket can point at *cancelled video consult* and everyone sees the same thing. - **Reusable.** The same examples feed tests, design review and documentation pages, so a state that is shown is a state that is exercised. - **Discoverable.** A reader scanning the list learns the component's states without guessing which control combinations matter. A playground alone hides states behind combinations. If *overdue* only appears when three controls are set a particular way, almost nobody will ever see it — and a state nobody sees is a state nobody tests. ## Choosing the examples 1. **Start from the spec.** Every documented variant and state gets an example. If the spec lists a state with no example, that is a gap to fill; if an example shows a state the spec never mentions, one of them is wrong. 2. **Add extreme data.** Long text, missing optional data, zero and many items, the largest realistic numbers. 3. **Add setup-dependent states.** Open, expanded, focused, loading and failed states that need interaction or timing to reach. 4. **Add combinations only where parts interact.** If a variant changes the layout that a state depends on, show that pair. Otherwise one example per axis is enough. 5. **Name examples by what they show,** not by test number: *checked-in, long pet name*. ## A worked example: the appointment card A veterinary clinic booking app shows appointments as cards. It has two variants — *clinic visit* and *video consult* — and states *upcoming*, *checked in*, *cancelled* and *overdue*. | Example | Why it exists | |---|---| | Clinic visit, upcoming | the default most people see | | Video consult, upcoming | the variant adds a join-call action and changes the layout | | Checked in | its own status treatment | | Cancelled, video consult | the join action must disappear; variant and state interact | | Overdue | its own warning treatment | | Long pet and owner names | wrapping and truncation | | No pet photo, no phone | fallbacks for missing optional data | | Loading | the placeholder while the card's data arrives | Eight examples cover what the full cross-product of variants, states and data would need dozens to show. ## Where property controls fit - **Exploration.** A designer tries a sentence of real copy; an engineer checks an input combination before writing an example for it. - **Generated from the component's declared inputs,** so controls never drift from what the component actually accepts. - **Seeded from an example,** so the playground starts in a known, meaningful state. - **Promoted when useful.** A combination someone discovers through controls and wants to keep becomes a named example. ## Coverage in one question For each component, compare the spec's list of variants and states with the list of examples. Every missing row is an unseen state. That comparison is cheap, and it is the most useful coverage measure a workshop has. ## Keeping the set current - **New state, new example, same change.** When the spec gains a state, its example arrives with the code that builds it. - **Retired state, deleted example.** An example showing a look users can no longer get misleads as badly as a missing one. - **Renamed state, renamed example.** Names are how people find and link examples, so they follow the spec's vocabulary. - **Periodic pruning.** Examples that no longer show anything distinct are merged or removed, so the set stays readable.
- Why not generate an example for every combination of inputs automatically?The count explodes, most combinations are redundant, and the few that matter drown among hundreds nobody reviews. Generated combinations can be useful as a smoke check that nothing crashes, but the catalog of record should be a curated set a person can read in a minute.
- A spec lists an 'overdue' state but the workshop has no example for it. What does that tell you?Either the state was never built, or it was built and nobody can see it. Both are problems: an unseen state is not reviewed, not tested through shared examples and not checked in each theme. Add the example, and if it cannot be rendered, the state is missing from the component.
saying these in an interview costs you the question
- A controls playground can replace named examples for every state.
- Every combination of inputs deserves its own example.
- Only the default state needs an example; the rest follow.
- Example names like 'test 1' and 'test 2' are fine.
- Extreme data belongs in tests, not in the workshop.