[RFC] Better consistency between Autocomplete and Select

[joshkel]

What's the problem?

I'm exploring replacing some of our Select components with Autocomplete components (using the default combo box mode). My assumption was that these would look and act more or less the same as Select components, with the added ability to filter the list by typing on the keyboard. However, the components have several differences in appearance and behavior:

1. Autocomplete's popup list is non-modal (the screen can still scroll). Select's is modal.
2. Autocomplete closes its list if the user switches to another tab or window. Select's list stays open.
3. Popup positioning differs: Select's tries to center around the Select component but constrains to the boundaries of Select's container, while Autocomplete's is more flexible. (See the demo - the Select component's popup is left-aligned with the Select component, due to the contraints of the surrounding Box, while the Autocomplete's is not.)
4. In dark mode, Autocomplete's list's background is a darker color than Select's (because Select's Popover uses an elevation of 8, while Autocomplete gives its Paper an elevation of 2).
5. Autocomplete's list is always the width of the autocomplete element. Select's list uses the Select element as a minimum width but can auto-size based on the menu contents.
6. Select's list uses a transition. Autocomplete's list appears immediately.
7. Autocomplete's list uses word wrapping. Select's list cuts off long items.
8. Select's list takes up to the full height of the screen. Autocomplete's is constrained to above or below the autocomplete element and is limited in height (beyond what's required by fitting above or below the autocomplete element).

What are the requirements?

Greater consistency and compatibility - avoid noticeable UX differences, unless there are clear reasons for them

What are our options?

Issues 1-3 (differences in modal, focus handling, and positioning) are likely the result of Select's use of Menu and Popover versus Autocomplete's use of Popper. This may be related to #38756.

Items 4-5 and (to some extent) 6 can be handled by changes to props and components, although I personally would appreciate not needing to apply these customizations myself.

Item 8 seems like a desirable difference: the autocomplete element needs to stay visible so the user can see what they're typing, and limiting the height seems perfectly reasonable.

(There may be UX issues I haven't considered that argue against changing any or all of these.)

Proposed solution

Some simple starting changes would include changing Autocomplete's Paper's elevation to 8 to match Popover and changing it to pass minWidth instead of width to the Popper's style.

Resources and benchmarks

https://stackblitz.com/edit/react-3apdzs?file=Demo.tsx has a side-by-side comparison of Select and Autocomplete, including a demonstration of some props and component changes to make Autocomplete more like Select.

Customizing Autocomplete width has come up before: #19376

Search keywords:

[ijxy]

Autocomplete, whilst convenient sometimes, does not work properly with hydration (it flickers, maybe the internal state management is relying on useEffect, which would explain it, but I haven't checked).

See for example with query strings. If you refresh the page, Select and TextField (select mode) hydrate immediately, whereas Autocomplete shows the empty state then hydrates with the value.

https://codesandbox.io/p/devbox/5swdg3

That is to say that any solution that makes Select/TextField similarly badly behaved during hydration should be avoided, IMO.

That said, if Autocomplete hydrated properly on initial render then I'd use it almost every time.

[mj12albert]

@joshkel Thanks for opening this issue ~ I think the inconsistencies you bring up would first be addressed by:

• [Select] Create new Select component base-ui#541
• [Combobox] Implement Combobox base-ui#222

[blarson-hearst]

Can we also add to the list size consistency? Select and Autocomplete sizes should match Button, TextField, etc as it requires extensive overrides right now.

It looks like this change was made in joy-ui, but wasn't made in MUI. Not seeing it in either linked issues either.
#38527