More in Frontend Dev — page 4
A federated design system governance model
WHAT IT TESTS: Scaling contribution via federation. OUTLINE: let the product team own the component as maintainers, with the core team setting standards, reviewing against a checklist, and owning the platform and tokens.
Driving and measuring design system adoption
WHAT IT TESTS: Strategy plus instrumentation for adoption. OUTLINE: lower friction with migration paths and great docs, incentivize over mandate, and measure adoption via package usage, component coverage, and code analysis.
Governance for design system contributions
WHAT IT TESTS: Designing a contribution and review process. OUTLINE: a clear intake and proposal step, review by core maintainers plus design, and criteria covering accessibility, API consistency, tokens, tests, and docs.
Classifying a Card change under SemVer
WHAT IT TESTS: Applying SemVer rules to a mixed change. OUTLINE: removing a prop is breaking so the whole release is major, document and migrate, and release the highest applicable level.
Documenting a single UI component
WHAT IT TESTS: Knowing what good component docs contain. OUTLINE: purpose and when to use, a props API table, live examples of variants and states, accessibility notes, and do and don't guidance. RED FLAG: documenting only the prop list with no usage guidance.
CI/CD pipeline for a design system monorepo
WHAT IT TESTS: Designing release automation for a monorepo. OUTLINE: install and cache, then parallel lint, type-check, unit and visual tests, then build, and on main a release job bumps versions and publishes. RED FLAG: publishing before tests pass.
Bundling a component library for tree-shaking
WHAT IT TESTS: Optimizing a library so consumers ship less code. OUTLINE: ship ES modules, mark sideEffects false, preserve named exports, and externalize peers so consumers tree-shake and code-split.
Releasing a breaking Button change with SemVer
WHAT IT TESTS: Handling breaking changes responsibly under SemVer. OUTLINE: bump the major version, write a changelog and migration guide, deprecate before removing where possible, and communicate clearly.
Automated visual regression testing for components
WHAT IT TESTS: Catching unintended visual changes automatically. OUTLINE: render components in known states, capture screenshots, diff against approved baselines in CI, and require human review of differences.
Packaging a design system as an npm dependency
WHAT IT TESTS: Distributing shared code as a versioned package. OUTLINE: publish to an npm registry, with package.json holding the version, entry points, and dependencies, and version it via SemVer.
Why design systems use Sass or PostCSS
WHAT IT TESTS: Knowing what preprocessors add over plain CSS. OUTLINE: Sass adds variables, nesting, mixins, and functions for reuse; PostCSS transforms CSS via plugins like autoprefixer. RED FLAG: claiming native CSS variables make them entirely obsolete.
Respecting prefers-reduced-motion in a design system
WHAT IT TESTS: Building motion accessibility into system architecture. OUTLINE: gate CSS animations behind the media query, read the same preference in JS via matchMedia, and centralize motion tokens. RED FLAG: killing all motion instead of reducing it.
Building an accessible combobox with ARIA
WHAT IT TESTS: Combobox ARIA wiring and focus strategy. OUTLINE: input has role combobox with aria-expanded and aria-controls, listbox holds options, and choose aria-activedescendant to keep focus in the input versus roving DOM focus.
Announcing status messages with ARIA live regions
WHAT IT TESTS: Announcing dynamic updates without stealing focus. OUTLINE: use a live region with aria-live polite or role status, ensure it exists in the DOM beforehand, and insert text to trigger announcement. RED FLAG: moving focus to the message.
ARIA roles for an accessible tab interface
WHAT IT TESTS: Correct ARIA wiring for tabs. OUTLINE: tablist contains tabs, each tab uses aria-selected and aria-controls, panels use role tabpanel with aria-labelledby, and arrow keys move between tabs. RED FLAG: making every tab a Tab stop.
Managing focus in an accessible modal dialog
WHAT IT TESTS: Keyboard focus management for modal dialogs. OUTLINE: move focus in on open, trap Tab within the dialog, close on Escape, and restore focus to the trigger on close. RED FLAG: leaving focus behind the modal in the background.
Associating a label with a form input
WHAT IT TESTS: Foundational accessibility for forms. OUTLINE: explicit association via for and id, implicit by wrapping the input, and why this gives screen readers an accessible name and larger click target. RED FLAG: using a placeholder as the label.
Shadow DOM encapsulation vs CSS Modules
WHAT IT TESTS: Understanding real browser encapsulation versus build-time name scoping. OUTLINE: Shadow DOM creates a separate tree blocking selectors both ways, CSS Modules only rename classes, and global styles need explicit bridges.
The polymorphic 'as' prop pattern
WHAT IT TESTS: Building reusable components with correct typing and ref forwarding. OUTLINE: render the element from an as prop, infer props from the chosen element, and forward refs. RED FLAG: ignoring types or dropping the ref.
Controlled vs uncontrolled Modal component
WHAT IT TESTS: API design judgment for component state ownership. OUTLINE: uncontrolled is convenient but inflexible, controlled gives parent full power and predictability, and a hybrid supports both. RED FLAG: claiming controlled is always better.