[Select] Create new Select component

[atomiks]

Preview: https://deploy-preview-541--base-ui.netlify.app/components/react-select/

• Closes [Select] does not accept slotProp: **placement** #547
• Closes [Select] On Safari, clicking on the Select input does not close its listbox #476
• Closes [Modal + Select] Using keyboard Esc while Modal's Select is open should not close the Modal #327
• Closes [Select] Using keyboard Tab while Select is open does not move focus to the next field #328
• Closes [Select] Implement new API #217
• Closes [Select] Select menu can't be closed by clicking away #8
• Closes [Select] The macOSVoiceOver doesn't read current value correctly on Safari #82
• Closes [Select] Support opening the Select and selecting an option with one click #66
• Closes [Select] Typeahead doesn't work on a closed Select #65
• Closes [Select] Mouse pointer doesn't steal focus on hover  #64
• Closes [Select] Highlight doesn't highlight properly if an Option has the value null #56
• Closes [RFC][Select] Rendering the selected value in SSR & during hydration #54 (solved via Select.Value placeholder prop)
• Closes [Select] Out of range defaultValue causes onChange to fire on mount #7 (TODO: provide a warning if defaultValue / value don't match any of the options)
• Closes [Select] SSR empty render  #37 (seem the same as [RFC][Select] Rendering the selected value in SSR & during hydration #54)
• Closes [Select] Set the onChange's event.target.value #14 (now invalid)

TODO:

• Integrate with useField
• Renamed alignMethod prop to alignOptionToTrigger

Olivier's edit: the v2 of mui/material-ui#8023 😄

[mui-bot]

Netlify deploy preview

https://deploy-preview-541--base-ui.netlify.app/

Generated by 🚫 dangerJS against 18ef2e8

[michaldudak]

It would be great if the Trigger had a CSS variable with the width of the popup, so it can match it (as in native OS controls)

[atomiks]

Do you mean the inverse? --anchor-width for popup is available. The trigger can't know the width of the popup when it's not mounted

[michaldudak]

No, I didn't mean the inverse. Native OS selects adapt their width to the longest option. Perhaps this could be an option when keepMounted=true.

[atomiks]

That's true, but I'm hesitant to add something that doesn't work by default. Furthermore, it's likely very performance intensive with longer lists to calculate as you'll need to measure every option with getBoundingClientRect to calculate the largest one. It also doesn't work during SSR, so will cause layout shift. It's likely something that should be hardcoded by the user if necessary.

[michaldudak]

Could you please review the list of reported Select bugs and set this PR to close the ones that will be fixed by it?

[flaviendelangle]

When you open the select, the page scrollbar disappears causing a layout shift on the right navbar in the doc (https://deploy-preview-541--base-ui.netlify.app/components/react-select/)

The @mui/material select also removes the scrollbar but there is no layout shift (https://mui.com/material-ui/react-select/)

[atomiks]

@flaviendelangle interesting. The padding-right: 15px for the scrollbar width offset once it disappears prevents the main content from shifting but not the right navbar content (and end of the top navbar)

[michaldudak]

I'm wondering if we should prevent scrolling by default at all. I find it annoying when I open a select and something else changes appearance (=the scrollbar disappears). Native implementations differ in this matter - iOS prevents scrolling but doesn't hide the scrollbar, while Windows closes the popup when the page scrolls.
IMO locking the scroll is more important in modal windows.

I found an issue that's likely related to scroll locking: https://codesandbox.io/p/sandbox/q7qfjg - when you open the select, there's a small layout shift and you're able to scroll the page horizontally until the whole trigger disappears.

[atomiks]

I'm wondering if we should prevent scrolling by default at all. I find it annoying when I open a select and something else changes appearance (=the scrollbar disappears).

The scroll locking changes we made in #604 prevents layout shift issues from disappearing scrollbars. The scroll lock is necessary with the item align anchoring because you can wheel the popup to reveal more items, but this can cause the page to scroll. It's not locked for the trigger align method.

I found an issue that's likely related to scroll locking: https://codesandbox.io/p/sandbox/q7qfjg - when you open the select, there's a small layout shift and you're able to scroll the page horizontally until the whole trigger disappears.

This looks like a bug with the .SelectPopup min-width style that doesn't limit itself by the --available-width.

This solves it:

  min-width: min(var(--available-width), calc(var(--anchor-width) + 20px));

There's a thread discussing default "functional styles" to apply to these elements and an API to override them in a thread in the base-ui channel. This could help prevent certain issues like this, including:

• Making the popup scrollable by default
• Limiting the popup's size to the available space (but the above calculation requires the user to use their own custom padding value)

[michaldudak]

This looks like a bug with the .SelectPopup min-width style that doesn't limit itself by the --available-width.

This solves it:

The repro was taken directly from the demos, so they'll need to have the styles updated.

[mnajdova]

1. What's the heuristic about giving up on the align option to trigger when close to the edge? I am asking because we have kind of a different behavior based on the options, e.g.

I would assume these two to behave the same way (we have space for the scrolling arrow in both scenarios).

2. Can we explain in this section why the change of the aligning affects whether the scroll is blocked or not. It could be surprising that just because you want things to be aligned differently it affects whether the scroll on the page is available or not.

3. Based on https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/, we shouldn't support circular navigation when using Up/Down Arrow => we should set loop: false in the useListNavigation.

4. Based on https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/ we should open the listbox when user types printable characters with setting active descendant on the right item:

If the combobox is collapsed and the user types printable characters, the listbox is displayed and receives accessibility focus via aria-activedescendant. This enables users to perceive the presence of the options, and enables assistive technology users to comprehend the size of the list of options.

5. Are we handling Home and End keys?

[atomiks]

1. What's the heuristic about giving up on the align option to trigger when close to the edge? I am asking because we have kind of a different behavior based on the options, e.g.

If the min-height is 100px or less (can be configured in their CSS), or if the reference is within 20px of the viewport edge, it falls back to standard anchoring. I felt the UX was much better in this case, matching macOS' fallback behavior.

Fair point!

Can change this, not sure if we should provide an option if so.

This seems to be a new pattern or suggestion that I haven't seen before, and the native select doesn't appear to do this. It doesn't seem critical to implement for now.

Yes, Home/End are handled

[michaldudak]

Can this be moved to InnerSelectOption? It seems that these values don't change on each option highlight (except maybe getItemProps?)

[atomiks]

Consuming the root context inside the memoized component is risky as any time the root context changes it will cause every option to re-render. Even if they don't change on each option highlight, they can change on other unrelated state changes. Minor refactorings could introduce issues unknowingly as well.

[michaldudak]

It seems that this provider can be rendered by InnerSelectOption

[michaldudak]

The performance of large lists is still not quite good. I played a bit with the profiler and identified that quite a lot of time is spent in FloatingFocusManager's handleMutation (https://github.com/floating-ui/floating-ui/blob/master/packages/react/src/components/FloatingFocusManager.tsx#L651). I initially thought that the slowdown may be caused by focusing each item on hover, but Radix does is as well and yet their Select feels snappier. IMO we can merge this PR so that this branch doesn't live for too long, but we should then investigate what can be done to make it even faster.