[combobox] Implement Combobox

[colmtuite]

Related Issues Each of these related issues should be considered when designing and implementing the new component. When this issue is resolved, these related issues should be closed.

• mui/base-ui#44
• mui/base-ui#45
• mui/base-ui#55
• mui/material-ui#44483
• mui/base-ui#27
• mui/base-ui#20
• https://github.com/mui/base-ui/issues/265

Related issues in Material UI's Autocomplete:

• mui/material-ui#23708
• mui/material-ui#23916
• mui/material-ui#25365
• mui/material-ui#31192
• mui/material-ui#31383
• mui/material-ui#32280

[oliviertassinari]

One challenge will be performance https://x.com/diegohaz/status/1848330344941982104.

Also to note that it took me 1,000 hr to get to a point where I started to be happy with the component. 200 hr for the first PR and the rest was iterating with the community on bug reports and feature requests.

[xndyz]

Any ETA on this?

[colmtuite]

@xndyz We are planning to ship it this year. But it will likely be Q4.

[atomiks]

Also to note that it took me 1,000 hr to get to a point where I started to be happy with the component. 200 hr for the first PR and the rest was iterating with the community on bug reports and feature requests.

This shouldn't take as long as Floating UI provides all the primitives already, similar to Select. The challenge there was more so the API design and working on Floating UI's core to support what we needed better.

[oliviertassinari]

@atomiks I'm not following, what's the link between Floating UI and a ComboBox? Almost all the complexity that I recall we have with an autocomplete component is in the behavior handling of events. Even having a great Select primitive won't help much. For example, I think this needs to be performant with 1,000 records without virtualization, and 10,000 with virtualization.

[atomiks]

behavior handling of events

@floating-ui/react (what we use) handles most of the events/interaction behavior in addition to the anchoring/positioning (at least for the most basic Combobox (old example)). With more advanced features it will increase time to build of course, since we need to create those from scratch.

The thread on list perf is interesting, wonder if Base UI should have a component for virtualization 🤔. Unfortunate that compound APIs are less performant than passing an array - will need to look into the offscreen trick

[oliviertassinari]

@atomiks Ok, then I think the point I want to make is that positioning didn't felt much of a challenge historicaly. I feel like we spend all our time when working on the combobox on managing those things:

• A ComboBox can be in a lot of different states (for a given UI context). Having them all yield amazing UX is hard
• A ComboBox can be used in a lot of different UI context. Having them all work well together is hard. By "UI context" I mean in the sense of, is this used as part of a big form, where you need to quickly move between field or is this one big search field, is this validating important state, where users needs to carefully validate the value to not have destructive impact, or should it be easy to fill, etc.
• A ComboBox internal code complexity can quickly explode, always striving to have the smallest possible codebase (bundlesize), simple possible solution, but still highly responsive (fast response and requiring as fewer and as many actions as needed by users to feel seamless).

I had a 1hr sync with Jed (author of https://github.com/JedWatson/react-select) in the past, where we discussed a bit what it took to build their ComboBox, the time they spent (3 iterations of 6 months), etc. I'm pretty convinced that anything below 500 hrs of work, if starting the work on the component from scratch would yield to a significant regression in the experience (depending on how the work is scoped, we can make some UI context work amazing not support others, but it's not a complet product yet).

[nivramam]

Can work on this

[uncomplexity]

Cool as hell. I wish this ends up being as cool and flexible as https://mantine.dev/combobox/.

[nassim-errahoui]

Hello, I'm currently using base-ui to build a system design. We're building a custom combobox while waiting for your component to be released. I'm looking for a scalable architecture that's easy to maintain. Looking at the way combobox popup content is done on other recent libraries, I see more or less 2 ways:

• either reuse shared components, as in Shadcn (Command)
• Or, as in this PR, the combobox has its own dedicated subcomponents (which I think is better for reducing interdependencies between components).

Both favor composition, but one is composed with dedicated components, the other with shared components.

So I was wondering, what is the philosophy behind base-ui? (I don't know if my question is clear, but I can clarify it if need be).

[github-actions[bot]]

This feature will be available in the next npm release of Base UI.

In the meantime, you can try it out on our Canary release channel:

npm i https://pkg.pr.new/@base-ui-components/react@2105