Component Library
The coded library behind a design system: its public API, composition model, theme hooks, accessibility, tests, versioning and packaging. Asked because API mistakes ship to every consumer.
part ofDesign systems & UX foundationsoverview, primer and where to startread it →on this pageshowhide
explore
- Props & Variants API4 questions
- Headless & Compound Patterns4 questions
- Theme Consumption & Overrides4 questions
- Accessibility Integration4 questions
- Workshop & Example Catalog4 questions
- Versioning & Breaking Changes4 questions
- Test Strategy Layers4 questions
- Package Layout & Formats5 questions
- Cross-Framework Delivery5 questions
- Right-to-Left & Locale Hooks5 questions
questions
page 2 of 2In a shared component library, a driver-app team used a button's polymorphic render-target property to render it as a generic container; what broke, and how should the API prevent it?
basics
~20 sThe styled container kept the button's look and pointer tap but lost its role, focusability and keyboard activation, so assistive-technology and keyboard users could not accept trips. The API should restrict render targets to semantically compatible ones and type the properties each allows.
A news publisher's shared story-teaser component has grown to forty properties; what does that signal, and how would you restructure it?
basics
~20 sForty properties signal over-configuration: one component absorbing every surface's needs as flags, with interactions nobody tests. Restructure into primitives, named slots for extension, and a few prebuilt recipes, keeping editorial invariants enforced inside the pieces.
A game companion app's design system ships thin wrappers for three UI frameworks, and months later the same item picker behaves differently in each; what went wrong, and how do you stop wrapper drift?
basics
~20 sWrapper drift happens when hand-written wrappers gain their own options, defaults and behaviour. Stop it with one machine-readable component contract that generates or type-checks every wrapper, a shared conformance suite run against each, and lockstep releases.
After a telecom self-service app adopts its design system's icon package, the bundle grows by hundreds of kilobytes although it uses twelve icons; what causes this, and how should the package be shaped?
basics
~20 sThe package defeats tree-shaking - usually a name-string lookup over a map of every icon, a single file, or registration on import. Ship one module per icon, imported statically, keep name-based lookup opt-in, and guard it with a size budget.
A vet booking app's workshop shows components only under the default theme, and a partner clinic's theme shipped an unreadable booking-status chip. How should the workshop change, and how do you measure its coverage?
basics
~20 sAdd a theme switcher that applies every shipped theme through the same mechanism apps use, render every example under each, and review a side-by-side view. Measure coverage as specified variants and states with examples, across themes.
A utility billing portal's component library used left and right spacing everywhere and must now launch in Arabic and Hebrew; how do you retrofit it for right-to-left?
basics
~20 sInventory every physical left/right use, convert spacing, alignment, radii, offsets and motion to logical start/end, take direction from the app's root, flag directional icons, then add a lint guard and both-direction checks so physical values cannot return.
A component library release passed all its own tests, yet the recruiter pipeline board in a consuming app broke on upgrade; what are consumer-contract tests, and how would they have caught it?
basics
~10 sConsumer-contract tests encode what real consuming screens rely on and run against a library release candidate before publishing, catching breaks in usage the library's own authors never tested.
A charity site's team restyled a shared library's amount picker by targeting its internal element names; after a minor library release the restyle vanished. What went wrong, and how should the library define override points?
basics
~20 sThe team depended on private structure the library never promised to keep. The library should publish a small, documented override surface — theme tokens, component override tokens, variants and a few named parts — and keep everything else private.
After a food-delivery app upgrades its shared component library from 4.6.2 to 4.7.0, the quantity stepper silently caps orders at 10 instead of 99; what went wrong, and how should the library team respond?
basics
~20 sA changed default is a breaking change shipped as a MINOR. Leave 4.7.0 as published, release a version restoring 99, flag 4.7.0 as faulty, and deliver the new cap as an opt-in or in 5.0.0.
For a shared component library used by thirty product teams, how open should the API be to passthrough attributes, host references and style overrides?
basics
~20 sOpen enough that teams never fork, closed enough that internals stay changeable. Most libraries curate: attributes pass to one documented element, a host reference points at the primary focusable node, style changes go through named override points, and escape-hatch usage is measured.
As design-system lead for a game companion app whose web teams use three UI frameworks, how do you decide whether to support all three, standardise on one, or deliver framework-neutrally?
basics
~20 sWeigh each framework's share of product surface and lifespan against the multiplied cost of supporting it, and the cost of teams rebuilding components if you do not. Usually the answer is tiered support with explicit entry and exit criteria.
In a multi-framework component library, why define a combobox's interaction behaviour once as a framework-agnostic state machine, and what must each framework adapter still own?
basics
~20 sInteraction rules are the costliest part to get right, so a render-free state machine lets every framework share one tested implementation. Each adapter still renders markup, binds platform input to machine events, moves real focus and runs side effects.
In a component library, what does treating workshop examples as test fixtures mean, and how should the mocked data behind them be built?
basics
~20 sEach example is defined once and reused by the workshop, tests and design review, so a documented state is a tested state. Its mocked data should come from deterministic builders with named scenarios, a frozen current time and no real records.
showing 31–43 of 43