Dropdown not showing all given options

[fabn]

Bug Report

Maybe I'm doing something wrong but I'm not able to understand what... I implemented an autocomplete component that uses algolia to get options and allow user to search in realtime.

By following that documentation I've used a Dropdown that receives hits as properties, shows them as option and refine search query while user types something.

The final result is pretty awesome but suddenly I realized that not all returned results are shown as dropdown options.

Steps

Here's a working demo of issue, you can try some searches to see that results are not the same, some values that trigger the "bug":

• 00100
• mil

But generally speaking if you search using dropdown and compare rendered results with other two panes you'll see that they are pretty inconsistent

Expected Result

Dropdown options should be same as list items in the middle

Actual Result

Not all options are rendered

Testcase

https://codesandbox.io/s/algolia-example-468ks

[welcome]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you've completed all the fields in the issue template so we can best help.

We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

[webciter]

i have got this issues with the dropdown remote data set as well, it deletes the keywords when searching again. But if i type space they show up.

[aninfeel]

It seems there is an internal text filtering works together with onSearchChange

[brianespinosa]

Hi @fabn!

Opening your test case in a new window and then opening the console will give us some clues: https://468ks.csb.app/

There are React duplicate key errors happening when searching for inconsistent terms. React needs keys for mapped elements to be unique... and the filtering is happening because it is not rendering any of the elements that have duplicate keys. Once there are unique keys being passed in to the search results, all elements should render as expected.

There is also another console error you have going on regarding switching between a controlled and uncontrolled component during render. I think that is unrelated to your duplicate keys issue though.

[pdfowler]

Unsure if we are seeing exactly the same issue, but our problem saw the internal text filtering in the getMenuOptions filtering out valid results from the server. We resolved it by passing the lodash _.identity function to the search prop of the dropdown. This ensures that all values passed in the options array are correctly displayed (and not filtered).

The root of our problem was that all fields being searched on the backend were not being populated into the text field (nor would we want to), so when searching for a user by their phone number, the text is the user's display name. The API returned the result, but the getMenuOptions function filtered out the matching users because the phone number was not in the text.

options = _.map(searchResults, user => ({ key: user.uuid, value: user.uuid, text: user.displayName }))
searchValue = '415';

// Search value exists in `user.phoneNumber`, but not in `user.displayName`

[fabn]

Unsure if we are seeing exactly the same issue, but our problem saw the internal text filtering in the getMenuOptions filtering out valid results from the server. We resolved it by passing the lodash _.identity function to the search prop of the dropdown. This ensures that all values passed in the options array are correctly displayed (and not filtered).

The root of our problem was that all fields being searched on the backend were not being populated into the text field (nor would we want to), so when searching for a user by their phone number, the text is the user's display name. The API returned the result, but the getMenuOptions function filtered out the matching users because the phone number was not in the text.

It was exactly my issue: search={(i) => i} will resolve my issue with the code linked in issue description.

So this is not an issue but a misunderstanding of search prop behaviour.

[Shubhdeep12]

Thanks @fabn