Combobox / autocomplete

[dandv]

Is your feature request related to a problem? Please describe.
I'm looking for incremental search for tags input.

Describe the solution you'd like
For inspiration, autocomplete in Evergreen and Fluent UI.

Describe alternatives you've considered
https://shoelace.style/components/select?id=help-text seems to focus on the option that starts with the typed character, but the search appears to stop there.

[claytongulick]

FWIW, I've done a fair amount of work on a pure web-components implementation here: https://github.com/claytongulick/chip-input it might be a good starting point / base for implementation?

[jaredcwhite]

@claytongulick This looks pretty cool! I'll try it out =)

[jaredcwhite]

Argh, I need sl-tag-autocomplete and I need it now! haha. Maybe I should try to cobble something together with a text field, tags, and dropdown menu…

[jaredcwhite]

It has begun! https://codepen.io/jaredcwhite/pen/LYbmwgz

Haven't gotten to autocomplete/dropdown yet, but the tag input works pretty well. =)

(type in anything and hit enter. clearing works too. el.tags works for tags-input at any time.)

@claviska Having fun with Shoemaker so far!

[claytongulick]

@jaredcwhite great start!

There are a ton of little details you'll have to think about, async autocomplete so you can call out to an API, formatting in autocomplete, positioning the dropdown, styling the widgets/pills, carrying data - having a display value vs linked object value, consumable events, etc...

Feel free to browse that chip-input code to see some of what I'm talking about, lift as much from it as you can :D

[sidharthramesh]

Any updates on this @jaredcwhite? I would really like to have an autocomplete in my project. right now, I'm doing some hackery with the <sl-input> and <sl-menu>

[jaredcwhite]

@sidharthramesh Well I'm not sure if my hackery is any better than your hackery, but here's what I've got so far!

https://github.com/whitefusionhq/sl-tags-input

I went ahead and published it because I need to use it in a project. Likely needs some more detailed API design and accessibility fixes, but it's working now for my needs. I can type, pull related results in from an external data source, and pick one, or type in one manually and hit enter. Add/delete tags. etc.

[sidharthramesh]

@sidharthramesh Well I'm not sure if my hackery is any better than your hackery, but here's what I've got so far!

https://github.com/whitefusionhq/sl-tags-input

I went ahead and published it because I need to use it in a project. Likely needs some more detailed API design and accessibility fixes, but it's working now for my needs. I can type, pull related results in from an external data source, and pick one, or type in one manually and hit enter. Add/delete tags. etc.

Very cool! I'll take a look

[sidharthramesh]

@jaredcwhite did you have this issue #382 (down arrow not working properly) while using a drop-down element inside lit-element?

[jaredcwhite]

You know, actually I did. That's why I ended up making SLMenu a slotted element in the Light DOM. If the bug gets fixed I might be able to simplify and move it into the Shadow DOM template.

[sidharthramesh]

Any idea why the behaviour is different when using the same markup inside lit-html?

This is unsettling because I'm using lit-element everywhere to wrap shoelace components into more general building blocks for my use case.

Is it something to do with the shadow dom?

[claviska]

@jaredcwhite @sidharthramesh this was fixed in 20eff47 and will be available in beta.35.

[sidharthramesh]

I can create a nice search bar, if the dropdown element had some additional props. I have made these changes here #385

[claviska]

I’m renaming this to align with the W3’s definition: https://www.w3.org/TR/2021/NOTE-wai-aria-practices-1.2-20211129/examples/combobox/combobox-autocomplete-list.html

For accessibility reasons, I think the scope should be more or less limited to what’s described here.

[hanc2006]

@claviska,
I prepared a PR for the sl-autocomplete component (code and doc), but I need to delete and create again the PR for the sl-datepicker component #474 and the PR for the i18n localization support #479. When I created the first fork I didn't think about creating new branches for each PR. Now I can't align the code with your upstream 😢

[claviska]

When I created the first fork I didn't think about creating new branches for each PR. Now I can't align the code with your upstream 😢

Sorry about that...things change quick sometimes, especially during beta. It's usually a good idea to limit one branch to one feature for that reason. I hope it doesn't create too much work for you!

[nkromm]

hey guys, what is the consensus on this topic now? The PR from @hanc2006 seems to be kinda stale.

[claviska]

Sorry, no update from my end. I'm focusing on other things that need to be done before removing the beta label.

[hanc2006]

Hi @nkromm, sorry for the delay. I am working a lot on a new project and at the moment I struggle to carry out this PR. @claviska I saw all the new features you introduced in the latest releases 👍. However I will try to finish this PR as soon as possible.

[luwes]

I put some effort in a similar component, feel free to steal some code of this;
Source: https://github.com/luwes/media-show/blob/main/src/input-list.js
Example (top right): https://media-show.vercel.app/

[nkromm]

@luwes Looks good in the demo!
Thanks for sharing gonna check it soon, as I am still interested in this.

[nileshtrivedi]

I tried to set up a combobox with sl-input and sl-menu both (a) with sl-dropdown and (b) without.

Unfortunately, both have serious issues with keyboard event handling.

https://svelte.dev/repl/a6f8e1e48a494a9eabbe7d879f0fbde6?version=3.48.0

[DeadWisdom]

Some thoughts:

• The W3 example uses a listbox, specifically. But other examples use a grid and another a datepicker, so it doesn't seem like that is necessary.
• It seems like we can't use an sl-menu here because, although it seems to align well, it takes over focus, but the input can't lose focus. Maybe you could quickly move back but somehow keep visual focus?
• It's exceedingly tempting to use an sl-select except with an sl-input instead of a button for the trigger or even just an sl-dropdown. But it would require modifying the sl-dropdown and/or the sl-select complicating their behavior a lot.
• The final solution should ideally allow for multiple kinds of panels to support things like a date-picker and maybe a datalist and maybe even a simple javascript list as a property. Perhaps that property could even take a promise or be a function that returns the list; that would be some nice DX.
• Would be awesome to allow multiple options, like multiple tags/chips, but maybe that's too much? Maybe start with a more limited scope. If the input is merely a slot, maybe that could allow extensibility to achieve this.
• Probably this should be implemented as two separate but integrating pieces. Perhaps an sl-combobox and then some other component that integrates, like an sl-menu or a new sl-listbox or sl-grid, or for clarity maybe something like an sl-combobox-list.

[yuki24]

I have made this component for my own needs, in case anyone is interested:

Screen.Recording.2022-07-29.at.12.00.09.AM.mov

I can send a PR as a starter and discuss the API if there is enough demand.

[nileshtrivedi]

How is Shoelace website's own search feature implemented?

[claviska]

It’s a makeshift script that doesn’t work properly with screen readers. I fixed that problem in Doxicity, but I haven’t had a chance to rebuild the whole website yet.

It’s even more of a challenge to get it right when composing a combobox with custom elements. Not impossible, but not exactly simple.

[atomkirk]

Just thought I'd pipe in and call for some overall vision planning here. In my experience, I've run into many variations of dropdowns/selects and they all share common elements, but are necessary for different scenarios. Pretty much all of these components are needed on a modern app so IMO a standard component library should support all of these use cases.

Here's the notes I've made over the years:

Selection Dropdown

Select one item from a short list.
Necessary for whenever one and only selection should be made from a short list of choices. The other alternative is radio buttons, which make more sense when each option is a long text. This is so common its built into the browser. It's just ugly.

Action Dropdown

A short list of actions to take.
This is nice at the top of a table for taking action on selected rows for example. It kind of groups similar items into one hidden UI item that doesn't clutter the UI until you need it/click on it.

Autosuggest

People call this autosuggest, but it's really a select dropdown where you can search the list of options.
This is great when the item is so long it'd be very tedious to scroll through it looking for the item to select.

Long Action Dropdown

Less common, but sometimes you have a really long list of actions you can take and the ability to search them is nice. Not planning to support this use case would be understandable, but I have seen it before…

Multi-Select

A dropdown that lets you select multiple items. The selections are shown as pills or chips or something. You can click them to deseletc.

Long Multi-Select

Same as Multi-Select but lets you search to select. Also similar to autosuggest, just allows selecting multiple things.

Another potential use case that I've never seen is selecting multiple actions and then selecting multiple actions from a long list with search. The difference between an action and selection categories is that the anchor or trigger component doesn't change where with select the anchor shows the current selection(s).

So the variables for the dropdowns I've needed over the years are:

• Selection or action
• Short or long (requiring search)
• Single or multiple selections

Things these all have in common are:

• There's some kind of popover containing the options.
• I think every one of these should let you provide your own component for the options rows. (e.g. showing avatars on a dropdown to select an assigned user.) That component should allow you to pass it the currently types string so the component can highlight matching content within the row.

I was king of thinking it might be a good idea for Shoelace to come up with a long term plan for how these things could fit into the offering. Whether thats as a single component or a few components, I think it'd be helpful to think ahead so that interfaces and code can be written with the long term plan in mind. I'm very willing to contribute and start to implement once you/we have that plan. You could make it all one component with options, you could make 2-3 components that use shared components common between them, etc. But I do feel strongly that all of these components are needed in most modern apps of even moderate complexity. Thanks for reading :)

[tpluscode]

I experimented a little on the sample provided by @nileshtrivedi

Here's an extract from my project's source code:

https://studio.webcomponents.dev/edit/3WC1qIWWF6aSTPA6ASKK/src/index.js?p=website

I think I got it fairly usable with two simple tweaks:

1. Preventing the default key event on space which would open the menu
2. Add a loading flag and automatically open/close the menu when it is toggled

[yuki24]

I have sent #1002 as a starter. While this is still missing a lot of things, you should all be able to give it a try on https://shoelace-git-fork-yuki24-combobox-component-shoelace.vercel.app/components/autocomplete. Would love any feedback on that. Thank you!

[chrisjameslennon]

I have sent #1002 as a starter. While this is still missing a lot of things, you should all be able to give it a try on https://shoelace-git-fork-yuki24-combobox-component-shoelace.vercel.app/components/autocomplete. Would love any feedback on that. Thank you!

Looks good. I think it just needs to auto drop down on click in.

[chrisjameslennon]

I guess the difference between an auto-complete input and a select control, apart from the visual aspects, is that an auto-complete will allow text that is not one of the suggested options. Not sure this needs to be a separate element? Perhaps could be a property of sl-input? However it is implemented this would be a welcome addition, as there is no current way to give the user suggested input in Shoelace it seems?

[claviska]

Accessibility remains the biggest hurdle, as we want to allow options to be defined declaratively but we can't link ids across shadow boundaries. It's not impossible, but it's definitely not trivial with the tools we currently have available.

[bcbweb]

Any progress on this? I like the idea of just augmenting the sl-input component to support this, e.g. via an autocomplete-data property