Capítulo 99 de 116
<select><select> follows the same controlled/uncontrolled split as <input> (Ch 98), but the selected value lives on the <select> element itself via value/defaultValue rather than on the individual <option> children — React diverges here from raw HTML, which marks the selected option with a selected attribute instead.
<select value={fruit} onChange={e => setFruit(e.target.value)}> — the parent <select> carries the current value; each <option value="..."> just defines what's selectable, none of them carry a selected attribute directly.<select defaultValue={initialFruit}> — same idea as defaultValue on <input>, letting the DOM own the selection after initial render.multiple attribute): value becomes an array of selected option values instead of a single string, and onChange needs to read e.target.selectedOptions (or similar) to reconstruct that array.selected to the chosen <option> — React's controlled model intentionally centralizes selection state on the <select> itself for consistency with how <input>/<textarea> work.<select value={fruit} onChange={e => setFruit(e.target.value)}>
<option value="apple">Apple</option>
<option value="banana">Banana</option>
</select>
<select>'s own value prop, not by a selected attribute on either <option>.value/defaultValue on <select> itself, never selected on an individual <option> — that's the one place React's API meaningfully diverges from plain HTML syntax.multiple, value is an array and reading the new selection from onChange requires iterating selectedOptions, not just e.target.value.<input> exactly — same mental model, different element.<input>): the controlled/uncontrolled pattern this element follows.<option> elements from an array typically needs key.