React-bootstrap-typeahead: minLength: 0 should be implemented

[boutell]

Currently minLength: 0 behaves like minLength: 1. In some applications it is quite useful to be able to fetch and display all of the possibilities right away because the number is small enough or they are cleverly sorted by likelihood of relevance. This can eliminate the need to use a different component for an almost identical use case.

[ericgio]

Currently minLength: 0 behaves like minLength: 1

That shouldn't be the case, and isn't, as far as I know. minLength: 0 displays results on focus, while minLength: 1 would require at least one character to be entered before showing the menu.

[ericgio]

Closing out as a non-issue. Feel free to reopen with repro steps or clarifying comments if you feel like I misunderstood your issue.

[prmichaelsen]

I am experiencing an issue where onSearch is not fired after the user clears their query when minLength is 0. If minLength is 0, I would expect onSearch to be called with '' as a parameter after the delay.

The logic in the source prohibits this.

(!query || minLength && query.length < minLength) should short circuit on !'' and return out of the handler without calling onSearch.

[ericgio]

@prmichaelsen: Correct, onSearch doesn't fire with an empty query (ie: ''). That's the intended behavior.

[prmichaelsen]

Hi, @ericgio, thank you for your fast response. This may be the intended behavior, but it doesn't seem correct. If the user can specify a minLength of 0 (which is valid according to the docs), then the onSearch should fire for empty queries.

Consider my use-case. I have a dataset of 1000+ entries. When the user has no query, we display a short list of likely relevant choices. This means if the user types a query, and then removes it, we would need to once again display the likely relevant choices.

[boutell]

An option to fire in this situation would be nice. I get that the empty
query would be a surprise to some.

On Thu, Jan 10, 2019, 12:36 PM Patrick Michaelsen <[email protected]
wrote:

Hi, @ericgio https://github.com/ericgio, thank you for your fast
response. This may be the intended behavior, but it doesn't seem correct.
If the user can specify a minLength of 0 (which is valid according to the
docs), then the onSearch should fire for empty queries.

Consider my use-case. I have a dataset of 1000+ entries. When the user has
no query, we display a short list of likely relevant choices. This means if
the user types a query, and then removes it, we would need to once again
display the likely relevant choices.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ericgio/react-bootstrap-typeahead/issues/171#issuecomment-453185319,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB9fRelbt2g2llZ00vwuMKMe8oZ8NGAks5vB3oogaJpZM4NEn3_
.

[prmichaelsen]

I get that the empty query would be a surprise to some.

Yes, I agree. Fortunately, I think minLength should provide some protection from users who were not expecting empty queries, should this feature be implemented.

[boutell]

Good point! minLength: 0 doesn't really have another reasonable
interpretation.

On Thu, Jan 10, 2019 at 12:41 PM Patrick Michaelsen <
[email protected]> wrote:

I get that the empty query would be a surprise to some.
Yes, I agree. Fortunately, I think minLength should provide some
protection from users who were not expecting empty queries, should this
feature be implemented.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ericgio/react-bootstrap-typeahead/issues/171#issuecomment-453187043,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB9fV2chih4Jm0TQNOxPLsu8zjRPXbFks5vB3tkgaJpZM4NEn3_
.

--

Thomas Boutell, Chief Software Architect
P'unk Avenue | [phone] | punkave.com

[ericgio]

@boutell, @prmichaelsen: It sounds like you're both using the async version of the typeahead. The behavior you describe doesn't exist in the basic version. minLength simply controls whether to display the menu. Displaying the menu without options is a valid state. The onSearch callback is independent (though related in the async case).

In your cases, how are you initially loading the suggested options when the user focuses the typeahead? Do those options change based on some criteria or are they always the same? If the latter, I would think there's no need to re-fetch when a query is cleared, right?

[prmichaelsen]

@ericgio, the problem is there is no way to inform my data provider that there is no longer a query.

Consider the following desired behavior:

1. No query: top ten results fetched from server and displayed
2. Query entered: top ten matching results fetched from server and displayed
3. Query cleared: top ten results fetched from server and displayed

Here is the actual behavior:

1. No query: top ten results fetched from server and displayed
2. Query entered: top ten matching results fetched from server and displayed
3. Query cleared: no new results are fetched, instead, the top ten matching results from the last fetch and _last_ query are displayed. This is because there is no way to inform the data request there is no longer a query.

[ericgio]

there is no way to inform my data provider that there is no longer a query

Sure there is. You can use onInputChange to get the current input value. onSearch is just a debounced callback being passed to onInputChange anyway.

Note that AsyncTypeahead is just an HOC that adds some simple debouncing and a basic cache to the main Typeahead component. It's provided with the library for convenience and to handle most simple async use cases. If it doesn't meet your needs you can easily write your own HOC that handles things exactly as you'd like them to.

[prmichaelsen]

@ericgio Thank you for the response. I can use onInputChange as a workaround, or just roll my own, I suppose. Thank you.