Component API Design for Frontend Interviews: Props, Events, and Trade-offs

Component API design is the contract between your UI component and the engineers who consume it. In frontend interviews, the answer is not just the JSX that renders; it is the React props, events, slots, state ownership, accessibility, styling, and escape hatches you choose not to expose.

Use this as a frontend component API design interview practice map. Start from a familiar component prompt, name the API contract, ship the MVP, then explain the trade-offs that would make the component scale in a team codebase.

Quick answer: how to design a component API

Start by naming the consumer and the state owner. Then define the props/events, composition model, accessibility contract, styling surface, and the escape hatches you are intentionally leaving for follow-up.

• Consumer: who uses the component, and what behavior must they control?
• State ownership: controlled, uncontrolled, or both through value/defaultValue callbacks.
• Props/events: public inputs and domain events with useful payloads.
• Composition: simple props, children, slots, or compound components.
• Accessibility and styling: labels, keyboard paths, focus policy, variants, className, and CSS variables.
• Score signal: clear contract, small MVP, explicit trade-offs, and no unnecessary escape hatches.

Component API decision matrix

Try the API surface trade-off

Toggle the same button prompt through three API surfaces. The strongest answer is not always the most flexible one; it is the API that matches the consumer and round scope.

<Button>
  <DownloadIcon aria-hidden="true" />
  Export CSV
</Button>

Component API design patterns interviewers ask about

These prompts expose different API decisions: controlled state, composition, event payloads, a11y contracts, styling hooks, and when to keep the surface area small.

Component API decision framework

Weak vs strong component API

Interviewers can usually tell whether you are designing from the consumer's point of view. A weak API adds one prop for every request. A stronger API names ownership, gives consumers a composable slot, and keeps events meaningful.

Practice note from FrontendAtlas drills: in timed component API drills, weak answers often add one prop per requested variation. Stronger answers first name state ownership, composition boundaries, and event payloads, then keep the initial API small enough to implement.

TypeScript API guardrails

TypeScript should make invalid component states harder to express, not make the interview answer feel like a type puzzle. Use types to protect the public surface, then move back to behavior, accessibility, and trade-offs.

Library patterns interviewers recognize

You do not need to copy a library API in an interview, but referencing familiar patterns shows that your design choices match real component systems.

The official docs below are references for the pattern vocabulary; adapt the pattern to the prompt, consumer, and timebox instead of copying a full library surface.

Worked examples: API contracts interviewers can score

Minimal example: these two types show the difference between state ownership and domain event payloads. In an interview, write only enough shape to make the contract testable before implementing behavior.

type DialogProps = {
  open?: boolean;
  defaultOpen?: boolean;
  onOpenChange?: (open: boolean, reason: 'trigger' | 'escape' | 'confirm' | 'cancel') => void;
  title: string;
  description?: string;
  children: React.ReactNode;
};

type SelectEvent<T> = {
  value: string;
  item: T;
  reason: 'keyboard' | 'pointer' | 'programmatic';
};

45/60-minute component API round flow

• Spend the first minutes clarifying consumers and state ownership.
• Define the public surface before coding.
• Use the final minutes to explain trade-offs and skipped escape hatches.

What interviewers score

• Clear contract: props, events, slots, and ownership are named before complexity grows.
• State ownership: controlled/uncontrolled decisions match the caller and prompt constraints.
• Event payloads: domain payloads carry useful data and reasons without leaking internals.
• A11y contract: labels, ids, ARIA linkage, keyboard paths, and focus behavior are explicit.
• Styling surface: variants, size, className, and CSS variables are enough without exposing everything.
• Trade-off narration: you can name the API you skipped and why it was not needed yet.

What to skip vs prioritize

• Prioritize the contract, a11y, state ownership, event payloads, and one dry run.
• Save compound components, render hooks, refs, and slot props for follow-up depth.
• Skip theme engines, virtualization, global config, and library-grade APIs unless asked.

Choose your next practice format

Component API design FAQ