Not possible to show nothing if no items match in Autocomplete

[peterbe]

The use case is when you use <Autocomplete> to allow a user to ignore all the suggestions but still proceed merrily. For example, for site-search. The input widget can suggest possible search term completions that match what's been input so far, but the user types beyond any of the suggestions and submits the form to make a full site-search.

If you set <Autocomplete.Menu emptyStateText={false} .../> (or null or undefined), this happens:

Earlier in the typing, when suggestions could be presented, it looked like this:

But, case in point, if the user ignores the fact that there exists no good autocomplete suggestion, completing the input does yield plenty of good site-search results:

[github-actions]

Uh oh! @peterbe, the image you shared is missing helpful alt text. Check your issue body.

Alt text is an invisible description that helps screen readers describe images to blind or low-vision users. If you are using markdown to display images, add your alt text inside the brackets of the markdown image.

Learn more about alt text at Basic writing and formatting syntax: images on GitHub Docs.

[peterbe]

CC @mperrotti @siddharthkp
This is the issue filed from our Primer Design Zoom chat.
(if you're wondering why I'm submitting this on US Thanksgiving, it's because I never fully submitted it after our last chat and now didn't want to lose the draft)

[lesliecdubs]

The general preferred approach here is to indicates there are no autocomplete suggestions, as mentioned in the interface guidelines for this component.

However, as discussed at Primer Patterns (as per @mperrotti), anytime a falsy value is passed for <Autocomplete.Menu emptyStateText={false} .../>, we could potentially change the component to not show the dropdown box UI at all in this case. However, we would need to check with accessibility on this before changing it. @mperrotti will take an action item on this and report back!

[peterbe]

The general preferred approach here is to indicates there are no autocomplete suggestions, as mentioned in the interface guidelines for this component.

Thing is, in my use case, I think a loading indicator is actually quite undesirable. I can't put my finger on it but apart from a flickering, it just doesn't feel great to display this. It's because free-text site-search is never expecting a perfect choice. Unlike, for example when I free-text type to find a GitHub handle, like when I type @peterb then, it's very desirable to wait until the selection option appears.

What I implemented, but later commented out, in my prototype was a slight delay. 90-99% of the time the server can very rapidly serve a response on the XHR request, so I didn't want the loading spinner to appear after every character typed (because, with a slight debounce).

However, as discussed at Primer Patterns (as per @mperrotti), anytime a falsy value is passed for <Autocomplete.Menu emptyStateText={false} .../>, we could potentially change the component to not show the dropdown box UI at all in this case. However, we would need to check with accessibility on this before changing it. @mperrotti will take an action item on this and report back!

If it can't be done (for the sake of accessibility), I'll implement something so that they empty-state text is a link similar to MDN's autocomplete. For example

  <Autocomplete.Menu
    emptyStateText={<p><a href={goSearchURL}>Search for <i>{typedInput}</i></a>}
  ...

By the way, let me know and I'd be happy to make a PR with the above-discussed change.

[peterbe]

Actually, I'd like to emphasis something; the most problematic is when you have nothing to suggest, yet, because the user hasn't typed a single character. (Nor, perhaps you have nothing in the local storage from previous visits)

On MDN the additional overlay does make sense, as a thing to say when there's no good autocomplete suggestions.

That's fine. But it's on the initial focus where it's tricky. E.g.

This feels more pressing than "have to have" an overlay to say something when nothing matches.

PS. I can sorta hack around this, myself, by injecting the top 5 most popular autocomplete suggestion independent of input.

[peterbe]

Another important note; as @siddharthkp cleverly figured out, if you attempt to NOT render the <Autocomplete.Menu> component, just because items.length === 0 then other bugs happen. For example, it will not allow you to type beyond as the component just keeps forcing the last suggestion back into the input box.