Add no results found property that shows message when no results are found for a given query

[drikusroor]

See also:

• No results Message mattzollinhofer/vue-typeahead-bootstrap#77
• initial pass at a 'no results found' implementation. mattzollinhofer/vue-typeahead-bootstrap#44

[darrinmn9]

@drikusroor thanks again for helping bring this project new life! I just wanted to share a few thoughts on this feature, since I implemented a "working but hacky solution" for this no results feature on top of the existing vue-typeahead-bootstrap component. I also shared some of my thoughts mattzollinhofer#44 (comment). Feel free to ignore the advice, your library your rules :), just an fyi.

I actually use vue-typeahead-bootstrap as a component for displaying autocomplete results i fetch from my server, (for example, returning cities from google places based on what the user types) and I set showAllResults to true. The server results are passed to vue-typeahead-bootstrap as the data prop, but if the server returns 0 results, I actually set the data prop array to [{ label: 'No matching city found', id: null }], while at the same time, setting the disabledValues prop to ['No matching city found']. By doing this, vue-typeahead-bootstrap would show my message in a "disabled" state (disabled=true for the listItem) so the user is not able to focus/click it, and also applying some default bootstrap styling for disabled list items.

Happy to discuss this further if you find this helpful. I did take a peek at your implementation, and also just wanted to ask/mention, by setting the noResults prop to default to No results found for {query}., have you effectively changed the default experience for this component? Would it be better to not supply a default string? so that the user of the component can explicitly "opt-in" to this new results functionality if they want it. While at the same time, existing users can upgrade from v2.14 to v2.15 without this change in UI/functionality by default?

[drikusroor]

Hi @darrinmn9, thank you for your comment! I will try to address your (original) thoughts and will also ask you for your opinion on my own thoughts. My apologies in advance for the size of the comment below. 😅 I had to structure it as not to get confused myself.

1. Disabled list item?

I actually use vue-typeahead-bootstrap as a component for displaying autocomplete results i fetch from my server, (for example, returning cities from google places based on what the user types) and I set showAllResults to true. The server results are passed to vue-typeahead-bootstrap as the data prop, but if the server returns 0 results, I actually set the data prop array to [{ label: 'No matching city found', id: null }], while at the same time, setting the disabledValues prop to ['No matching city found']. By doing this, vue-typeahead-bootstrap would show my message in a "disabled" state (disabled=true for the listItem) so the user is not able to focus/click it, and also applying some default bootstrap styling for disabled list items.

I actually went for the exact same route for the project in which I'm using this component and it is also one of the reasons I made this fork. 😄 But are you saying it might be better to display it as a disabled list item here as well to keep things consistent?

2. (Not) changing default behavior of component

Happy to discuss this further if you find this helpful. I did take a peek at your implementation, and also just wanted to ask/mention, by setting the noResults prop to default to No results found for {query}., have you effectively changed the default experience for this component? Would it be better to not supply a default string? so that the user of the component can explicitly "opt-in" to this new results functionality if they want it. While at the same time, existing users can upgrade from v2.14 to v2.15 without this change in UI/functionality by default?

That is an excellent point and it would indeed be better to not change default behavior.

3. minMatchingChars

Regarding your thoughts on the original PR:

if query does not meet minMatchingChars, I don't see a reason to show a no results found message. As the prop docs state, minMatchingChars -> Minimum matching characters in query before the typeahead list appears. If that minimum isnt met, typeahead list shouldnt appear and nor should a No results found state. "No results found" tends to imply, I attempted to find a match, but couldnt. Whereas if the query doesn't meet minMatchingChars, the component never attempted to find/show a match in the typeahead.

I'm not sure if I understand the point you are trying to make. Are you saying we should check for minMatchingChars as well?

4. {query} placeholder

Do we want to provide access to the
characters the user has already typed as part of a custom message?

This is pretty trivial for the user to do themselves since they have access to v-model="query", I'm not sure if taking on the additional complexity internally will be much value... especially as I mentioned, imo, most users will want to override message this anyways.

Also an excellent point... We don't need the {query} placeholder per se.

5. Markup

Related to the above: I was also toying with the idea of allowing markup (make query bold for example), but I'm not sure what would be a nice approach for that. Do you have any ideas / opinions on that?

6. External data scenario

Lastly, I'm not sure we have covered the scenario in which one uses an external API with a search feature to supply data to the component. Consider the following scenario:

1. User types a query
2. Query gets propagated as a search term in an http request
3. Response data is an empty array []
4. Empty array is used as the data prop for vue-bootstrap-autocomplete.
5. However, the list component currently won't be displayed if data is an empty array (v-show="isFocused && data.length > 0") While we probably do want to show a No results found message there.

Conclusion / tl;dr

1. Are you proposing we should display the No results found message as a disabled list item?
2. My intention is now to remove the default "No results found for {query}" value as not to change the default behavior of the component.
3. Should I take minMatchingChars into account and / or was that your original point?
4. My intention is now to remove the {query} placeholder as the consumer of the component has access to that value anyway and can pass it along in the noResultsInfo prop.
5. What would you think about adding markup functionality and how would you approach that?
6. What are your thoughts on the external data scenario and showing a "No results found" message when the data prop is actually an empty array?

[darrinmn9]

1:
I would actually be curious what other open source solutions do for this. There might be some a11y concerns at play. I cant claim to be an expert so I was just adding my 2 cents. Definitely the "no results" item shouldn't be clickable or focusable, but it should be accessible to screen readers.

https://designsystem.digital.gov/components/combo-box/ In this example, hovering over the "no results" item shows cursor: not-allowed with tabindex="-1" (no focus allowed)

https://alphagov.github.io/accessible-autocomplete/examples/ is similar, they even make the text more "gray" to distinguish it visually from an actual result (where the text is darker)

Both of these solutions still treat the "no results" as a list item (<li> inside of <ul>) and not just a <div>

3:
The docs say minMatchingChars is "Minimum matching characters in query before the typeahead list appears". I assume most people use it as a way to basically not annoy the users with results/dropdown list until they've typed "enough" characters to search correctly. So in that sense, if the current query doesnt meet minMatchingChars to show the typeahead list, then for consistency sake, the "no matching results" shouldnt show either, since (imo), "no matching results" is basically the negative state for having the typeahead list show. The user should have to type the minMatchingChars for either the results or no results to show.

4 / 5:
As an alternative approach, this could be an optional slot, which allows the user of the component to customize the markup/messaging as they see fit. This is more of an unopinionated approach, but sometimes more ideal as it gives the user more control. Or even follow the same pattern as prepend/append, they are both props and slots, but as the docs say, the slot overrides the prop.

[darrinmn9]

6:
I would think "no results found" should display for an empty array (given the query meets minMatchingChars)... but i cant anticipate every usecase. That is why having an optional prop/slot is a good idea imo - it's less opinionated and gives control to the component user. The user can detect the array is empty and decide whether or not to pass in a "no results" prop/slot. The component internals can just check if the prop/slot was supplied before deciding whether or not to add the markup

[drikusroor]

Merged #5 that

• has an optional noResultsInfo prop and slot
• uses <ul> and <li>
• adds a disabled class
• sets tabindex="-1"
• sets aria-selected="false

[darrinmn9]

awesome!!!