Day 2 — Design a reusable filter component
The product now needs the same selection control in several places. Replace the fragile one-off API with a reusable component.
Requirements
FilterMenu must be controlled: the parent owns its selected value.
- Support a stable
id, visible label, disabled state, options, and a semantic value-change callback.
- Preserve generic string-literal types so callers cannot select a value outside their options.
- Do not add state to
FilterMenu merely to mirror its value prop.
Interview review
- Why is
onValueChange less misleading than onChange in this API?
- When would a compound component API be a better choice?
- How would you add async options without changing this component’s controlled contract?