Combobox updates before V1

[Barsnes]

We have some issues and API changes we want to make to the Combobox before V1.
This issue is a collection of issues we want to fix

Tasks

Preview Give feedback

1. Combobox: issues reported by Axe #2578
   ♿️ accessibility 🐛 bug +2
2. Combobox (next) - Controlled - Flickers when setting value to Leikanger #2338
   🐛 bug +1
   
3. Combobox - Cannot reset controlled combobox #2264
   react 🐛 bug +2
   
4. Combobox does not work on VoiceOver Safari #2322
   ♿️ accessibility +1
5. Combobox: Virtualization causes JAWS to read the list of options incorrectly #1732
   react ♿️ accessibility 🐛 bug +3
6. Combobox: null, undefined and empty string as value causes react to crash #1663
   react 🐛 bug +2
7. "Add new value" functionality to the combobox component #1408
   1 of 4
   💡feature request +1
   
8. Combobox - selecting a filtered value resets the input #1595
   react 🐛 bug 🕵️ investigate +3
   
9. Scroll to selected item when opening Combobox with multiple: false #2702
   react 💡feature request +2
10. Combobox list should close when focus leaves component

Some of these might already be fixed, but the issues have not been closed.

Some key points:

• We have noticed that floating-ui adds a lot of fluff like aria-hidden
• Controlled state has issues, we should consider rewriting this internally (see things to explore below)

Things to explore:

Should we change the API? This depends on our other form components, and a key discussion point here is having an API to place input, tags, etc. - This might need to be discussed after the points listed below.

It has been suggested to use u-tags and u-datalist. We can explore this.
A pros is that it seems to work for a simple combobox. A con is that we might lock ourselves into not being able to add more functionality to our combobox, which is the main reason why we wanted to create this component without a library. We want to add a Combobox.Custom, loading, and the ability to add a custom value. There might be a middleground to this, but usage of this needs to be thoroughly investigated.

Should we still have a fake focus? Currently the input always has the real focus, and the options has a virtual focus. Could we handle this better by moving focus when the user starts typing? pros/cons?

Can we use the popover api to handle the list? This would mean we can drop floating-uis portal, which we have seen issues with.

Does virtual items work today, could it be improved? We use @tanstack/react-virtual today, which has been nice to work with, but is it nice to use for end users?

Our controlled state has some edgecases we have not accounted for (see linked issues in tasklist). Should we rewrite this? This should come after the points above have been discussed and explored.

This is currently the only cmponent where you can use a portal. This means that data-color and data-size will not work for anything that is inside a portal. We should explore using the popover API here.

[mimarz]

Examples of use with large datasets, and slow open:

• https://virksomhet.brreg.no/nb/oppslag/enheter
• https://codesandbox.io/p/sandbox/dropdown-open-sync-forked-5t46dh

[mrosvik]

Meeting Notes – Combobox Functionality

Date: 12.11.24
Attendees: @mimarz @eirikbacker @Barsnes @unekinn @mrosvik

Purpose of the Meeting
Define the functional and accessibility requirements for the combobox component.

Should support:

• Explore u-elements to see if it can be used in our combobox. Use u-elements if possible.
• Should be modular, allowing developers to assemble the components themselves.
• Multi-selection
• Starting with autocomplete, where the list is filtered, would be a good approach. It should be easy to hook in custom filtering and adjust behavior when interacting with specific list items.
• Enable customization so users can build additional functionalities on top
• The component should always be "controlled". (If you want to split it up, it’s easier for the consumer to manage the state themselves, rather than us offering both controlled and uncontrolled versions.)
• Creation mode: Should users be able to create items that are not in the list? We want to support that this is achievable, but we need to experiment to determine how
• Support fetching data from an external APIs. There should be a loading state for this.
• Supports for users to display no filter results.

Should not support:

• Should not support internal virtualization. Users must handle this themselves.

Browser and screen reader compatibility:

• Today's combobox meets all accessibility requirements, and that’s the challenge. 🤷🏻‍♀️ Even when it does, it still doesn’t work properly. On Android 13, results aren’t read aloud at all. For iOS users, nothing is announced; it's completely silent when you navigate. A range of other operating systems/browsers also struggle with this.
• Test with Axe: Combobox: issues reported by Axe #2578

Next Steps and Follow-up

• We should deprecate the Combobox we have
• We should create an experimental new Combobox for V1.
• We should experiment with the new combobox and have a follow-up meeting to decide if the new combobox should be part of V1.
• Create a submodule with experimental components? So that it is completely separated. The path can be changed when it is remoted. Responsible: @mimarz
• @eirikbacker will create a minimal example with u-elements, that @Barsnes can explore further.