Build a reusable UI component

Components built from a mock-up usually cover only the state in the mock-up. In production the data is late, empty, failing, or three times longer than the design assumed, and someone is using a keyboard or a screen reader. A reusable component also needs an API other engineers can guess: typed props, sensible defaults, composition instead of a pile of boolean flags, and no hard-coded copy.

Build a react component from this description:

[DESCRIPTION]

Styling: match project (when it says "match project", find and use the project's existing approach and design tokens).

1. If you were given an image, list what you can read from it (layout, hierarchy, text, controls) separately from what you are guessing (exact spacing, colours, hover states). Map colours and spacing to the nearest existing tokens instead of hard-coding values.
2. Find two existing components in the repo and copy their file layout, naming, prop style, styling method and test approach.
3. Design the API: typed props with defaults; controlled and uncontrolled use if it holds state; slots or children for content that varies; callbacks named for intent (onSelect, not onClick2). Expose a ref to the root element (a ref prop in React 19, forwardRef before it) and pass remaining attributes and class names through where the framework allows it.
4. Implement every state that applies: default, loading (skeleton or spinner with aria-busy), empty (message plus a next action), error (message plus retry), disabled, and overflow (long text, many items, narrow viewport).
5. Build accessibility in: native elements first (button, a, input, dialog), an accessible name for every control, full keyboard operation, visible focus, contrast from the tokens, and respect for prefers-reduced-motion.
6. Take all user-visible text through props or the project's i18n layer. Hard-code no copy.
7. Write tests in the project's framework for each state, the main interactions (including by keyboard), and the callbacks. Add an automated accessibility check if the project already uses one. Add a story or demo entry if the project has Storybook or similar.

• No new dependencies unless the description requires one; prefer what the project has.
• Do not change shared tokens, global styles or other components.
• If the description and existing design-system components overlap, reuse or extend the existing one and say so instead of building a duplicate.
• Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
• Keep the change as small as it can be while still being correct.
• Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
• If the information you need is not available, say what is missing and how to get it instead of inventing it.

Assumptions

What you inferred or guessed, one line each.

API

| Prop | Type | Default | Description |

Code

Each file in its own code block, headed by its path.

Tests

One line per test: what it proves.

Usage

A short example covering the default and error states.