Composing Input and Button into a SearchForm

WHAT THIS TESTS This checks the fundamentals of composition and API design: can you assemble existing primitives into a focused component with a clear, predictable interface rather than building everything from scratch.

A GOOD ANSWER COVERS SearchForm should reuse the existing Input and Button rather than duplicate their logic, placing them inside a form element so native submit handling and Enter-to-search work for free and accessibility is preserved. For props, accept the things a consumer needs to control: value and onChange for a controlled query string, placeholder text, a loading or disabled flag to reflect an in-flight search, and optionally a button label. For events, the key output is an onSearch callback fired on form submit with the current query, so the parent owns what happens with the term, such as fetching results or updating the URL. Keep SearchForm presentational and controlled, leaving data fetching to the parent, which keeps it reusable across contexts.

COMMON WRONG ANSWERS Reimplementing input typing or button click behavior instead of composing the existing components. Hardcoding the search action inside SearchForm so it cannot be reused for different queries. Making it fully uncontrolled so the parent cannot read or reset the value.

LIKELY FOLLOW-UPS How would you add debounced live search? How do you handle controlled versus uncontrolled value? How do you forward extra Input props through SearchForm?

ONE CONCRETE EXAMPLE SearchForm receives value and onChange to track the query, a loading flag to disable the Button and show a spinner, and an onSearch callback. The user types, presses Enter or clicks Search, the form submit handler calls onSearch with the value, and the parent component performs the fetch and renders results, while SearchForm stays purely about input and submission.