Autocomplete

A View that stacks Autocomplete.Label, the trigger and Autocomplete.Description / .Error with one gap, so JSX order is screen order. It is the column and the help lines that make this a field on a form rather than a button that opens a list — and they are the TextField's, token for token, so a text field and an autocomplete on the same form read as one control. The DatePicker borrows the same three slots for the same reason.

isInvalid paints the trigger's border and turns the label and the description danger; it never mounts or unmounts Autocomplete.Error. A slot that silently renders nothing is one you cannot debug, so you write the condition yourself:

<Autocomplete isInvalid={Boolean(error)}>
  <Autocomplete.Label>État</Autocomplete.Label>
  <Autocomplete.Trigger>
    <Autocomplete.Value placeholder="Choisir un état" />
    <Autocomplete.Indicator />
  </Autocomplete.Trigger>
  …{error ? <Autocomplete.Error>{error}</Autocomplete.Error> : null}
</Autocomplete>

Autocomplete.Trigger stays the field: it keeps its own ref — it is the node the panel measures — and its own a11y props. Autocomplete.Overlay and Autocomplete.Content portal out, so they add nothing to the column.

A select is for a list you read: a dozen options, all of them visible, and choosing is recognising one. An autocomplete is for a list you cannot read — fifty states, four thousand cities — where choosing is finding, and the field you type in is the control rather than an extra row in a menu.

Same trigger, same panel, same rows; a different thing to do with them. So the two share their style by construction: the trigger, the panel and the rows resolve through selectRecipe, and only the search box and the empty line are this component's own. A second table would be two to keep in step, and the drift would show as a select and an autocomplete side by side in a form with fields half a shade apart.

The rows are plainer than a select's for the same reason. No description, no check: a check beside the row already chosen is of no use in a list you reached by searching for something else.

Autocomplete.Search lives inside Autocomplete.Content, and the panel pins it above its scroller so it stays put while the results move under it. It takes focus as the panel opens — an autocomplete you have to tap twice before you can type into it is a select with a spare row — and autoFocus={false} turns that off for a panel short enough that the keyboard would cover it.

The query goes with the panel. Closing clears it, because a search that survived its own closing would mean the list is already filtered the next time it opens, by a word nobody can see. query / defaultQuery / onQueryChange if you would rather own it.

What matching means

geneve finds Genève, and genève finds Geneve — diacritics are folded and case is dropped, both ways.

york finds New York: it matches any word rather than the first, because a long list is searched by whichever word someone remembers, not by the one that happens to come first.

An empty query keeps everything, which is what makes the field's resting state the whole list rather than none of it.

Autocomplete.Content drops the rows that do not survive the query. It reads them the way Autocomplete.Value reads the chosen label — off the elements, before any of them mounts — but only its direct children.

Walking deeper to read a label changes nothing; dropping a row nested inside a component of your own would mean rebuilding that component's children for it, and a filter that silently rewrote your tree is worse than one that leaves it alone. A row wrapped in something of yours is a row the search will not hide.

A row with no readable label is never hidden either — hiding it would make a custom row disappear the moment anyone typed.

And only when nothing matched. A panel that filtered its last row away and showed an empty box reads as a control that has broken rather than as a search that found nothing.