[Select] Consistency with Autocomplete

[skoging]

• I have searched the issues of this repository and believe that this is not a duplicate.

Summary 💡

Equivalent to react-select's isSearchable={false}.
Disables the search functionality, but is still consistently styled.

Examples 🌈

Motivation 🔦

Having consistent styling of searchable and non-searchable selects is a requirement we're currently facing.

This workaround works: https://codesandbox.io/s/material-demo-ok1kg, but it's not exactly pretty.

EDIT:
Updated workaround with readOnly prop on input suggested by @cooperjones: https://codesandbox.io/s/material-demo-vh5lx

[oliviertassinari]

@skoging What's the incentive for using the Autocomplete instead of the Select component if you "remove" the textbox? I mean, I believe both components styles are very close, what do you miss?

Maybe #18493?

[cooperjones]

I am also implementing both searchable and non-searchable selects and am running into a similar issue making them consistent (I'm attempting to use the Select component for non-searchable selects).
A big difference between the AutoComplete and Select components is the positioning method for the listbox. The Select component uses the Popover component which forces focus and blocks scrolling, while the AutoComplete component uses a Popper which allows scrolling and does not block focus. This leads to differences in the tabbing logic, menu positioning, etc., between the two components.
Additionally, the dropdown icon in the AutoComplete component uses an IconButton w/ separate interaction & hover/focus styles whereas the dropdown icon in the Select component uses a non-interactable svg element.

Not sure if this is a workable solution (I haven't had a chance to explore the a11y ramifications or test on less common platforms/browsers), but adding a readOnly attribute to the input element of the AutoComplete component seems to be a pretty good work-around to get a non-searchable combobox. The readOnly attribute maintains the listeners on the text input element (onFocus, onClick, onBlur, etc.) while also preventing any text from being entered.

[eps1lon]

@cooperjones I think we'll revisit the Select with regards to Popper vs Popover. The current solution has a mobile first approach where the Popover makes more sense. But for a select input on desktop a Popper makes more sense.

Need to do some research though first and see how this is used.

[oliviertassinari]

@eps1lon 💯👍 .

@cooperjones Thanks, so to sum-up, we have the following difference:

• 1. The Select positioning is different from the Autocomplete fixed in v5.

vs

This can be configured with the Popover placement props to be identical:

<Select
  MenuProps={{
    getContentAnchorEl: null,
    anchorOrigin: {
      vertical: 'bottom',
      horizontal: 'center',
    },
    transformOrigin: {
      vertical: 'top',
      horizontal: 'center',
    },
  }}
>

Actually, I'm even wondering if we shouldn't make it the default, per the latest specification:

• 2. The scrolling behavior is different. We have a couple of related issues to this: [Select][material-ui] Don't lock the body scroll and make it non-modal select #17353, [Menu] Clicking outside a menu blocks click from bubbling up #11243 or [Popover] On mobile Chrome while zoomed, opening popover causes page to jump #17636 (comment). I do think that it's something we should consider as important and at the minimum provide an opt-in prop. Should the capability to scroll be opt-out? Or change based on the platform? This I don't know. It would require some research. You can also expect a unification on this dimension.
• 3. I think that the difference of interaction with the dropdown icon is justified by the presence/none-presence of a textbox. Is it safe to say that it's a detail, not important?
• 4. There is a significant difference in terms of performance. While the Select uses the MenuItem > ListItem > ButtonBase > TouchRipple rendering chain, the Autocomplete uses a li for each option. Performance issue on multiple select #17806. I believe the rendering difference is in the order of magnitude, but to be confirmed with a rigorous benchmark. This is the difference between rendering 240 items below 100ms and above. However, we might have another per issue with the Autocomplete, I see a forced reflow from the scrollTop = 0 logic:

• 5. In multi-select mode, the Autocomplete's popup closes as soon as one option is selected, the Select doesn't. I believe the behavior of the Select is wrong. See [Autocomplete] Don't close the popup when Ctrl/Shift clicks #19654 for more details.

[skoging]

Thanks for the response to this issue. It's good to see that it has generated a discussion around the differences and inconsistencies between Select and Autocomplete, both when it comes to styling and performance.

I think @cooperjones highlighted the main incentives for using Autocomplete as a Select, and in addition the performance differences mentioned can be very noticable.

With the readOnly workaround being much less hacky, this isn't a particularly high priority issue for us. In my opinion the focus should be on getting the Autocomplete component stable and into core. Then perhaps take look at the future of the Select component, using the lessons and experiences gained implementing the Autocomplete.

[bmulcahy]

So this disables the text input but how do I disable the clear and drop down?

So I was able to do it by setting freeSolo={true} disableClearable={true} and doing the readOnly work around from above

[Nziranziza]

I have added these but It doesn't seem to work for me

<Select
  MenuProps={{
    getContentAnchorEl: null,
    anchorOrigin: {
      vertical: 'bottom',
      horizontal: 'center',
    },
    transformOrigin: {
      vertical: 'top',
      horizontal: 'center',
    },
  }}
>

[oliviertassinari]

@Nziranziza It's expected, there isn't enough space to display the whole list below the select.

[oliviertassinari]

So far, we are waiting for the reimplementation of the Select (e.g. to use Popper over Popover) before closing this issue.

[danielpza]

So far, we are waiting for the reimplementation of the Select (e.g. to use Popper over Popover) before closing this issue.

@oliviertassinari is there an issue or PR to keep track of the progress?

[oliviertassinari]

No, consider, this issue and all the other open issues as part of the same underlying problem. The Select likely deserves to be rewritten from scratch at this point.