Config option to have search input in popover

[j-manu]

If the search input is in popover,

1. When an option is pre-selected, you don't have to clear it to search
2. Aesthetically I find it more pleasing for select 😄

An example of search input in popover - https://ui.shadcn.com/docs/components/combobox

[josefarias]

I definitely want to keep an approach that's simple and very close to web standards. For that reason, this library is closely modeled after the APG's reference implementation of a combobox, which doesn't have the input in a popover.

I think putting it in a popover adds a bit of complexity. I'd welcome a PR attempting it, but it's a decision I'll likely make based on the complexity of the implementation.

I don't currently have plans to implement this myself.

[jlw]

The other possible benefit I see to this UI is making the feature discoverable. We have a bunch of comboboxes in a React app I maintain and I've recently seen several user recordings where people don't realize they can type to filter, so they scroll through hundreds of options. I think that problem might also be solved with placeholder text.

(I'm intending to submit a clear widget PR in the next week or so which would also address part of the problem by making the clear action simpler.)

[josefarias]

@jlw i had this conversation on X today:

(I'm on my phone where adding alt text is cumbersome, let me know if you need that and I'll add - sorry!)

I'm interested in supporting the clear search button soon as I think it's a legit painpoint.

Would you mind sharing the work in progress? Or, possibly detailing the implementation plan in an RFC discussion?

I'd like to provide early feedback to reduce the chance of redundant work.

[jlw]

@josefarias - here's the changes I still had in my working directory from a few weeks ago: main...jlw:hotwire_combobox:clear-widget

IIRC, I got this to the point where the hidden input would clear, but the filtering was still active when I re-engaged with the element. Although I rebased my changes onto your latest main branch just now without testing anything, this branch had been back on e0a0f8b

[josefarias]

@jlw nice work! I see some potential for simplification. If you're up for it please create a PR (can be a draft if you prefer, but I don't really care) and we can collaborate there.

[josefarias]

I'm gonna call it a "no" for now. Sorry to disappoint!

I agree there's something to be said for the discoverability of the feature. But here's my reasoning for not implementing right now:

1. HotwireCombobox was modeled closely after the APG example — for better or worse. It wasn't designed to have the input inside the listbox.
2. I anticipate supporting both designs (inline and within-listbox) will require some branching in the keyboard navigation code, as well as some auto-focusing logic. There might also be accessibility concerns, so we'd also have to branch in the markup to label everything properly. I'm weary of complicating the code further unless absolutely necessary.
3. So is this absolutely necessary? I don't think so. Discoverability (which I think is the strongest argument for doing this) can be achieved in other ways. Could be outside the library (via explaining copy, labels, placeholders, etc) or within the library (could maybe add an option to include instructions inside the listbox: e.g. "type to search..." — which would be simpler than moving the input)
4. Adding yet-another place where the query appears adds state to manage — which we're already juggling a ton of state. I worry what that means for maintainability.
5. I subjectively really like the simplicity of the current combobox. Sure, hard to discover at first. But once that up-front cost is paid — it's paid for good. You never have to teach it to users again. Whereas with the within-listbox design the component looks more busy every time it's used, even when users already know how it works.

Not saying I won't change my mind on this at some point. But I am saying it's gonna take a good argument and possibly a good amount of convincing.

I know this isn't what some people wanted to hear. Sorry about that! Can't build everything for everyone without creating a monster.