AsyncTypeahead: Previous menu options not cleared before next search

[NateFaulkenberry]

Version

6.0.0-alpha.6 (though I believe this bug exists in version 5 as well)

Steps to reproduce

1. Navigate to the Asynchronous Search on the example page:
   https://ericgio.github.io/react-bootstrap-typeahead/#asynchronous-searching
2. Enter "the" into the input - search results for "the" will display in the menu - expected
3. Delete "the" from the input - the menu will close - expected
4. Enter "test" into the input - the previous options for "the" will render in the menu for the duration of delay prop on AsyncTypeahead component - unexpected

Expected Behavior

The menu should display the value for searchText prop when a new search begins

Note: I did try several workarounds to clear the options using onMenuToggle prop, however this produced unwanted side effects

Actual Behavior

The menu displays options from the previous search results

[CRAKZOR]

using onInputChange should work

  onInputChange={(text) => {
      if (!text) {
          setOptions([])
      }
  }}

[NateFaulkenberry]

using onInputChange should work

  onInputChange={(text) => {
      if (!text) {
          setOptions([])
      }
  }}

This does work. Thank you for sharing! However, I would argue there is still an unwanted side effect when using the onInputChange workaround you've suggested. Rather than rendering the previous search result options, the menu instead renders "No matches found" (or whatever the value set by emptyLabel prop happens to be). I'm sure there's a workaround for this too - but I think it makes sense for the author of this (very useful and well-built) library to consider this behavior a bug. In my opinion, anytime the search input is cleared the user is starting a new search, making searchText the desired message to render.

[ericgio]

This is a longstanding behavior in the component (see #248). I admit that it's weird, but I never found a good way to address it internally. As you observed, it's related to the input debouncing. @CRAKZOR's suggestion was also the suggested workaround on the other task.

@NateFaulkenberry: I'd love your help with this if you feel inclined to debug some more. Otherwise this is probably a wontfix.

Duplicate of #248

[NateFaulkenberry]

@ericgio, understood. Thank you for your response! If I get a chance to poke around the code and happen to find a solution I'll be sure to submit a PR. In the meantime I'll stick with @CRAKZOR's suggestion. Thanks again for creating a great open source component.

[savageqm]

any update on this issue?