AsyncTypeahead: filtering options in onSearch requires filterBy to be overriden

[janhapke]

Not sure if this qualifies as a bug, but it took me a while to figure this out so maybe it's at least worth a note in the documentation.

I have a list of Ids (numbers 0 - 999) and want the users to be able to search for both 123 as well as 123 (with spaces before and/or behind) and still get results. So I implemented an onSearch function that does a .trim() on the query. When searching for 123, everything worked as expected, but with 123 , AsyncTypeahead would report "No matches found." although my onSearch function would provide the correct results as options.

Turns out that the default filterBy implementation of the non-async Typeahead is still there and being applied to the result of my custom AsyncTypeahead onSearch function.

"Disabling" the filterBy of the AsyncTypeahead fixed the issue: filterBy={() => true}

Version

5.1.1

Steps to reproduce

• Implement custom logic in AsyncTypeahead's onSearch function, for example .trim() the query
• set options based on result of custom logic

Extremely reduced example (see sandbox for working version):

const allOptions = range(0, 1000).map((num) => {
  return { id: num, label: 'Id #' + num };
});

const [options, setOptions] = useState(allOptions);

      <AsyncTypeahead
        id="example-1"
        onSearch={(query) => {
          const matches = allOptions.filter(
            (item) =>
              query === '' || ('' + item.id).indexOf(query.trim()) !== -1    //  <--  filtering happens here
          );
          setOptions(matches);
        }}
        filterBy={() => true}    //  <--  default implementation of filterBy would filter again if not explicitly overridden
        options={options}
      />

Sandbox: https://codesandbox.io/s/react-bootstrap-typeahead-windowing-example-forked-9giog?file=/src/index.js

Expected Behavior

• All options that result from the custom onSearch logic are available for select in the dropdown

Actual Behavior

• "No matches found".

[ericgio]

Hi @janhapke, thanks for opening this issue and sorry you had trouble with this. The behavior you describe is the expected behavior, and the method of disabling you describe is called out in the filtering documentation. As mentioned in #578 however, it might be worth making that the default for the async component.