Component Design and Reusability Questions

Concerns designing reusable software components and component libraries, commonly in user interface and application architecture contexts. Topics include evaluating component complexity, deciding when to build a single reusable component versus multiple variants, designing clear component APIs and props, state management and composition patterns, handling edge cases and accessibility concerns, documenting behavior and usage, testing and versioning components, and strategies for promoting reuse across teams. Emphasis on balancing flexibility against API simplicity, ensuring maintainability, and providing examples of component evolution and trade offs.

EasyTechnical

68 practiced

How should iconography and image assets be managed in a component library to ensure reuse and consistent rendering? Discuss file formats, size variants, naming, and export strategies for web applications.

MediumTechnical

72 practiced

Design an API for theming that maps design tokens to component styles. Compare using CSS variables with JS-driven token injection (CSS-in-JS). For each approach, discuss runtime theming, performance, and how a designer can preview theme changes in Storybook.

Sample Answer

**Approach summary**I’d map design tokens (colors, spacing, type) to a theming API that exposes a token palette and two implementation layers: CSS variable-driven and JS-driven (CSS-in-JS). As a UI Designer I care about fidelity, preview speed, and handoff.

**CSS variables (recommended for runtime theming)**- How it works: export tokens as :root custom properties, e.g.:

css

:root {
  --color-primary: #0055ff;
  --space-4: 16px;
}

- Runtime theming: swap a theme class (or change :root) to update all components instantly; supports prefers-color-scheme and system-level toggles.- Performance: native, hardware accelerated, minimal repaint (only affected properties), great for large apps and SSR.- Storybook preview: load theme variants as decorators or use controls to toggle classes; designers can live-edit vars to iterate.

**JS-driven token injection (CSS-in-JS)**- How it works: tokens fed into component styles at render-time (styled-components, Emotion):

const Button = styled.button(({ theme }) => ({
  background: theme.colorPrimary,
  padding: theme.space4
}));

- Runtime theming: powerful (dynamic calculations, component-level overrides) but may require re-rendering and style regeneration.- Performance: good for scoped overrides; can cost runtime CPU if themes change frequently or many components re-render.- Storybook preview: integrate ThemeProvider and knobs/controls to modify token object; easier to show component-level token overrides.

**Trade-offs & recommendation for UI Designers**- Use CSS variables for broad app theming, quick previews, and performance; it maps cleanly to design tool tokens (exportable).- Use CSS-in-JS when you need per-component computed tokens, JS logic, or encapsulation.- For Storybook, provide both: global decorators that toggle CSS variable sets and a ThemeProvider control for JS-driven examples so designers can prototype both global and component-scoped variations.

MediumTechnical

74 practiced

List and explain a testing strategy for UI components in a component library that includes unit tests, integration tests, accessibility checks, and visual regression. Provide specific tools you would use and one example test for a Modal component.

Sample Answer

**Overview — testing strategy (goals)**- Ensure correctness, accessibility, and visual consistency of components in the design system so developers implement faithful UI from our visuals.

**1) Unit tests**- Purpose: verify component API, props, and small interactions.- Tools: Jest + React Testing Library.- Focus for designers: visual props (size/variant), aria attributes, and visible content.

**2) Integration tests**- Purpose: interactions between components and focus/keyboard flows.- Tools: Playwright or Cypress.- Focus: opening Modal, focus trap, backdrop click, keyboard Escape to close.

**3) Accessibility checks**- Purpose: automated a11y regression and CI gating.- Tools: axe-core (jest-axe), Storybook a11y addon, manual keyboard + screen reader spot checks.- Focus: role, aria-modal, focus order, contrast.

**4) Visual regression**- Purpose: catch unintended style/layout changes.- Tools: Chromatic (Storybook), Percy, or Playwright + pixel compare.- Focus: snapshots across breakpoints, dark/light themes, motion-reduced states.

**Example test for Modal (unit + a11y)**

javascript

// Modal.test.jsx - Jest + React Testing Library + jest-axe
import { render, screen, fireEvent } from '@testing-library/react';
import { axe } from 'jest-axe';
import Modal from './Modal';

test('Modal opens, traps focus, and is accessible', async () => {
  const onClose = jest.fn();
  render(<Modal isOpen onClose={onClose}><button>Confirm</button></Modal>);

  // content visible
  expect(screen.getByText('Confirm')).toBeVisible();

  // focus trapped: first focusable is focused
  expect(document.activeElement).toBe(screen.getByText('Confirm'));

  // keyboard escape closes
  fireEvent.keyDown(document, { key: 'Escape' });
  expect(onClose).toHaveBeenCalled();

  // a11y check
  const results = await axe(document.body);
  expect(results).toHaveNoViolations();
});

**Notes**- Integrate Storybook stories and Chromatic snapshots for visual checks.- Run axe and Chromatic in CI; use Playwright for cross-browser interaction tests.

HardTechnical

95 practiced

Edge-case handling: propose how to design a Dropdown component that gracefully handles unusual cases: very long option lists, dynamic content size changes, nested scrolling containers, viewport collision, and keyboard navigation. Describe internal behaviors and public API options you would expose.

Sample Answer

**Clarify goals & constraints**Design a Dropdown that feels reliable and accessible across complex layouts: supports very long lists, dynamic item sizes, nested scroll containers, avoids clipping/collision, and fully keyboard-operable.

**Internal behaviors**- Virtualization + incremental render: render visible window + buffer; maintain stable item heights when possible, support variable heights with dynamic measurement and window recalculation.- Adaptive positioning: prefer a flip/shift strategy — open below, flip above if insufficient space; detect available space in ancestor scrolling containers and window viewport.- Portal rendering with scroll anchoring: render menu into a top-level portal by default, but calculate transform relative to the trigger so nested scrolls don’t clip it; subscribe to ancestor scroll/resize to reposition.- Collision handling: apply max-height with internal scroll; when menu would overflow, resize and enable internal scrolling; animate transform origin to preserve perceived attachment.- Keyboard & focus management: roving tabindex, typeahead search, Home/End, PageUp/PageDown navigation; Escape closes and returns focus to trigger; ensure aria attributes (aria-haspopup, aria-expanded, aria-activedescendant).- Dynamic content: observe size changes (ResizeObserver) and reflow; preserve scroll position and focused item when list changes.

**Public API (props / design tokens)**- maxVisibleItems / maxHeight / itemHeightEstimate- virtualization: boolean | options (overscan, variableHeights)- appendTo: 'body' | selector | null (inline)- collisionStrategy: 'flip' | 'shift' | 'constrain'- position: 'auto' | 'bottom' | 'top' | coordinates- onOpen / onClose / onPositionChange callbacks- keyboard: { typeahead: boolean, pageSize: number }- accessibility: role overrides, custom aria props- visual tokens: elevation, borderRadius, spacing, animationDuration

**Design considerations & trade-offs**- Virtualization reduces DOM cost but complicates keyboard indexing and typeahead — expose stable IDs and smooth focus mapping.- Portals solve clipping but break CSS inheritance — provide style hooks and tokens.- Keep defaults accessible and simple; expose advanced props for developers.

This balances robustness, accessibility, and visual control for designers and implementers.

HardTechnical

87 practiced

Accessibility and internationalization combined: describe how you'd design a DatePicker component to support right-to-left languages, different calendar systems, keyboard navigation, screen readers, and dynamic locale-based formatting. Highlight API and internal component patterns to surface in documentation.

Unlock Full Question Bank

Get access to hundreds of Component Design and Reusability interview questions and detailed answers.

Join thousands of developers preparing for their dream job.