Select: add an options-driven convenience API for the single-select case

Inizia leggendo l’API composta Select esistente e il punto di ingresso di autocomplete/search-in-content. Traccia come sono attualmente rappresentati i valori single-select, le etichette, le opzioni disabilitate e i gruppi prima di scegliere la posizione e i tipi del wrapper. Il lavoro è completato quando l’API aggiuntiva supporta opzioni piatte, opzioni raggruppate, modifiche controllate del valore, placeholder, icone iniziali e menu ricercabili senza modificare l’API composta.

Summary

Select only ships a fully-compound API (Select + Select.Trigger / Select.Value / Select.Content / Select.Group / Select.Label / Select.Item) plus a multiple union. The overwhelmingly common case is a single-select driven by a list of options — "here are the choices, here's the value, tell me when it changes." Every such call site has to hand-assemble the compound tree, which is a lot of boilerplate for the 90% case.

What every consumer ends up writing

To render one single-select, a consumer writes the trigger, the value (with placeholder + selected-label logic), the content, and maps options to items — then repeats it everywhere. We wrap it once into an options-driven component so call sites can say what to choose instead of how to render the menu:

<Select
  value={value}
  onValueChange={onChange}
  placeholder="Pick one"
  options={[
    { value: 'a', label: 'Apple', leadingIcon: <AppleIcon /> },
    { value: 'b', label: 'Banana' },
  ]}
/>

...plus a groups variant for headings, and searchable for the in-dropdown filter. It's a thin wrapper, but it's one that essentially every Apsara consumer needs and rebuilds independently.

Request

Add an options-driven convenience API for the single-select case, either as props on Select or as a small dedicated component. Ideally it accepts:

• options (flat) or groups (with headings)
• per-option label, value, disabled, optional leadingIcon
• placeholder, value / onValueChange
• searchable (wires the existing autocomplete/search-in-content)

The compound API stays for advanced layouts; this is purely additive sugar for the common path. It would also give the single-select case a cleaner type than the current multiple discriminated union, which a single-select consumer has to narrow around.

Willing to contribute

Happy to open a PR if you'd like this in-library rather than re-wrapped per consumer.