Autocomplete component

[hamvocke]

I've started building an autocomplete component that can be used for type-ahead search, e.g. for searching tags, users or anything else, really.

This is still a work in progress but I wanted to get some things out here to kick off discussions.

• currently the autocomplete component will only respond with the same, static data.
• there's no debouncing yet
• autocomplete supports arbitrary elements to display results, this includes popovers
• rudimentary keyboard navigation is working (esc to blur, tab to select)
• displaying a loading indicator while a query is running works

Some points I want to put up for discussion:

1. How opinionated do we want the autocomplete component to be? Right now I can declare an arbitrary element to display autocomplete results. I can use popovers and anything else, really, and I think that's spiffy! Check out the examples to get a feeling for this. Alternatively we could always tie the autocomplete component to a popover component but I don't think this will make declaring an s-autocomplete much easier.
2. How much keyboard navigation do we want to provide? Right now, I can use the browser's own tab and shift-tab navigation as long as the autocomplete results are hyperlinks. This is pretty ideal from an accessibility perspective and flexible. The problem is that this is a component that has interaction with arbitrary backends which do the actual search. We need to rely on convention that these server endpoints return autocomplete results that we can navigate through, that's why I'd rely on browser standards (like tab to select the next anchor) to build keyboard navigation. If developers want to provide special behavior when selecting (i.e. hitting enter on) a single autocomplete result, I'd let them implement that event handler themselves
3. Where should the debouncing functionality go? Implement our own and have it part of the autocomplete component for now? Pull in a dependency?

[bnickel]

Warning: I'm giving off some negative vibes in this feedback. I think this is fundamentally a good idea, we just need to be clear and realistic about what this can and can't deliver.

Autocomplete is a Very Hard Problem™️ so it would be good to clarify the scope of what you're trying to accomplish with this component. "Searching tags, users or anything else, really" requires some intense JavaScript.

Stack Overflow's basic autocomplete component is like 800 lines of JavaScript with at least 11 points of customization. It does things like partial searches on tags, so "java php<caret>" will submit a request for with ?q=php but "java<caret> php" will submit a request for ?q=java. You can see this for yourself in the "Watched Tags" sidebar component.

The rich tag editor is 1200 lines with 30 points of customization. Custom Filters devotes several hundred lines to things like positional operator and tag filtering. Teams uses the component for mentions with their own set of customizations and hooks.

Then there are things like mention autocompleting in comments, which can be either in a textarea or div[content-editable] and performs partial autocomplete based on the presences of an @.

Essentially, if you want to write a general use autocomplete widget, you're going spend months ironing out all the requirements and edge cases and making sure it's extensible in the ways it needs to be.

If you're just working on a suggestion loader, something that doesn't necessarily serve as an auto-complete, but a list of clickable items that don't necessarily feed back into the input, things become much simpler and your concerns really shift back to just presentation and keyboard navigation. I would brand it as something other than autocomplete though as it has a very specific meaning.

I do really like the work on standardizing what search suggestions look like, and would love to see more design work on that. We tend to be all over the place in how we do that so some Stacks standardization of that.

[hamvocke]

Thanks, Brian. I strongly agree that we should have a clear baseline of what this component is and what it isn't.

My tendency is to avoid the one-size-fits-all component here. You mentioned a couple of cases where we're using autocomplete behavior already:

• tag search
• @ mentions in dedicated mention fields (as seen on teams)
• @ mentions in free text (comments and questions)
• type-ahead site search

Fitting everything into the same component will inevitably make it explode in complexity. Ideally, we'd come up with a component that's composable over a component that's reusable for every use case we can imagine.

a suggestion loader, something that doesn't necessarily serve as an auto-complete, but a list of clickable items that don't necessarily feed back into the input

That pretty much fits the bill of what I'm looking for. I understand that autocomplete is a loaded term in our context and I don't want to make this component pretend to be something that it clearly isn't. I'm all up for renaming it as much as I'm up for clearly defining the scope of this component in order to be useful and not too complex.

Do you want us to look at the requirements together?

[netlify[bot]]

✅ Deploy Preview for stacks ready!

Name	Link
🔨 Latest commit	a5a5d623172b1c52752cf5e892d9d043d43b6c7c
🔍 Latest deploy log	https://app.netlify.com/sites/stacks/deploys/628bc929a5253e00088456aa
😎 Deploy Preview	https://deploy-preview-372--stacks.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[dancormier]

This PR hasn't been meaningfully updated in > 4yrs, so I'm gonna close it