Kendo-ui-core: Autocomplete minLength broken

[dustbort]

Thanks for the great library! I am aware of issue #431 and it still seems that the current implementation of autocomplete as a result of #241 is broken. If minLength is going to be included as a configuration option, then it should have consistent behavior for both adding and deleting input characters. It seems to me that the primary intent of minLength was to prevent too many results from being _returned from_ the server, not just to prevent _calls to_ the server, and that returning all results when then input is cleared is a regression of this intent.

When I try the autocomplete demo at http://demos.telerik.com/kendo-ui/autocomplete/serverfiltering , because minLength=3, I have to type 3 characters to get a result. It also means that when I delete a character and leave two characters, it does not widen the result to match those two characters, and when I delete another character to leave one character, it again does not widen the search. Then why, upon deleting the last character and leaving zero characters should the search results explode to return all results? If the argument is that user expects results that match the input string of length zero, why is it not considered confusing to the user when results are not updated for inputs of lengths 2 and 1? Doesn't this also violate some expectation of the end user? It really feels like a regression and a kludge to solve #241, resulting in violation of intent of minLength. Resolution of #241 to return all results should have been for the case where inputLength == 0 AND minLength == 0, not just inputLength == 0.

If app developer A wants to return all the results when all input characters are deleted, then app developer A can set minLenth=0, since this app developer doesn't care much about the number of results being returned from the server. But now app developer B that cannot allow too many results when the input length is zero is forced to go change the server API to limit the number of results there. So the usefulness of minLength is diminished to the point that I wonder why it was included as a config option to begin with? Simply to avoid a few calls to the server in cases 0 < inputLength < minLength at the expense of returning all results when inputLength == 0? We can argue that there should always be a limit on the number of results returned from server API, but this does not clarify the original intent of minLength and whether that is in conflict with resolution of #241. In the current implementation, I will probably never use minLength and would always just cap the results on the server side. Thanks.

[ggkrustev]

Hi @dustbort,

Thank you for the thorough explanation of your statement. Indeed, the initial intent of the minLength option was to increase the specificity of the filter value and thus limit the result of the returned data.
This behavior, however, was reported multiple times as unexpected and non-intuitive. The end users expected to see something when whole text is cleared. Before the change done in #241, there was no feasible workaround that we could suggest to those users. That is why we decided to change the implementation and initiate a filter when input is cleared. This filter, however, can be easily prevented in the filtering event handler:

function autocomplete_filtering(e) {
  if (!e.filter.value) {
    e.preventDefault();
  }
}

That being said, current behavior is intended and we do not have any immediate plans to change it.

If you believe that we could enhance current behavior, please open a UserVoice discussion on the subject.

With the given explanation from our side, I will close this ticket. For enhancement requests, please open a UserVoice discussion where the people can share their thoughts and respectively to vote.