How to ignore outdated search result?

[Screeze]

Hi,

if the user types kind of fast and the search queries to the backend return in a different order, currently the wrong search results are shown.

Example:

1. User types "a"
2. Backend query for "a" sent
3. User types "b"
4. Backend query for "ab" sent
5. Backend query for "ab" returns -> List shows correct results
6. Backend query for "a" returns -> List shows incorrect results

I could handle this on service base with recognizing the last sent query and ignore any other result. But I don't know how to tell the widget to ignore the return value. If I would return an empty value, the search results would be empty until the correct query returns. Instead I want to leave the current search result and don't provide something new.

Is this possible? If yes: how?

[thedanielhanke]

id you try ng-model-options="myptions" with having e.h. $scope.myoptions = {debounce: 300}; defined in your controller ?

300 for 300ms.

https://docs.angularjs.org/api/ng/directive/ngModelOptions

[guylabs]

Hi Ralf,

I would try the debounce hint from @thedanielhanke and I will change this behavior as part of the #57 as there I will change how the items-method is called and then the list won't get cleared and will stay and you have more control on what is shown.

@thedanielhanke thanks a lot for the hint!

Thanks and regards,

Guy

[Screeze]

@thedanielhanke : Not sure if I understood that correct, but doing something like

<input ion-autocomplete type="text" readonly="readonly" class="ion-autocomplete"
        autocomplete="off" max-selected-items="1" items-method="searchLocation(query)"
        ng-model="test.location" item-value-key="id" item-view-value-key="displayName"
        placeholder="Start typing..." loading-icon="android"
        ng-model-options="{ debounce: 1000 }"  />

Would only delay the selected value - not the live updates for the search list, right? At least it doesn't seem to work as expected.

[Screeze]

@guylabs :
Sounds great! :) Thanks for your effort!

[thedanielhanke]

@Screeze debounce would not only delay, it also resets the delay when the input value is changed within that period - or as the documentation tells: " and/or a debouncing delay so that the actual update only takes place when a timer expires; this timer will be reset after another change takes place."

in your case, like it does in mine, this should lead to:

1. User types "a"
2. delayed request for "a"
3. User types "b"
4. 2. gets reset to 1000 to become delayed request for "ab"
5. delay expires
6. Backend query for "ab"
7. Backend query returns -> List shows correct results

ng-model-options="{ debounce: 1000 }" seems to be correct. is your input still queried immediately while editing?

[Screeze]

@thedanielhanke Sure, I know what it should do.
But in this case, it doesn't. Even with a debounce value of 5.000 requests are fired immediatly.
The reason is the following:

I define the debounce on a text-input which defines the autocomplete. But the actual input of texts does not happen in this input. It happens in an overlay, generated by the autocomplete, with this input field:

<input type="search" class="ion-autocomplete-search ng-valid ng-dirty ng-valid-parse ng-touched" ng-model="viewModel.searchQuery" placeholder="Start typing..." style="">

The debounce is added to the input which is part of my form, not the search-input. So the debounce would delay writing back the selected value, probably, but it does not delay the search queries.

[guylabs]

Hi Ralf,

well if it is possible I can get the debounce attribute from the outter input field and then pass it to the inner input field such that this works. What do you think about that?

Thanks and regards,

Guy

[Screeze]

That would be an idea. Unfortunately this has may have the side effect, that also writing back the data from the selected value to the viewmodel could be delayed, right?
Would not be a problem for me, but not sure about others.

[guylabs]

Hi Ralf,

I just updated the behavior of the items-method you can also try the branch and then tell me if that is now better for you. See this comment: #57 (comment)

And I will have a look at the debounce thing to try to add it on the inner input field.

Thanks and regards,

Guy

[guylabs]

Hi Ralf,

I just added the ability to pass the ng-model-options to the inner search field. Can you please test this on the master and give me feedback such that I can close the issue?

Thanks and regards,

Guy

[guylabs]

Hi Ralf,

any news on this? I want to release 0.3.1 this week.

Thanks and regards,

Guy

[Screeze]

Hi,
sorry for the delay.
I just tried the debounce option, and it works great. I'm just not sure if also debouncing the actual model update is a good idea? (But for the moment it doesn't seem to cause any problem)

I also tried the possibility to return undefined as search result to not clear the results, and it seems to work well. Not sure though, how I can make this smart (like: showing results if the search is more up to date then the shown results, but not returning anything if the shown results are already newer then the current search.) But that's something I can solve with some counter logic probably.

I'm just wondering, if for future versions, this could be some mechanism implemented within the autocomplete itself. Now i have 4 autocompletes within my application, querying 4 different endpoints, which all would need that logic. If this was in-built, it would be a lot easier.

Maybe for a future version, you could think of something like this:
You hand over an integer with each query to the callback. The integer gets ++ed for each query. When results are returned, the callback must also provide the integer back to the autocomplete, together with the results.
You could then remember the latest returned integer and compare it with the current returned integer. If the newly returned results, have a lower int value, then ignore it. If it is greater, then use it.
That might require an API-break, or a second "items-method" attribute, with that functionality included, or another option, enabling that feature.
But I assume this is some kind of problem anybody has, who uses the autocomplete with an API (especially on mobile connections)

Kind regards and thanks for your work,

Ralf

[guylabs]

Hi Ralf,

ok nice thanks a lot for testing. Well I think if you use a decent debounce value then this issue can be minimized such that it just occurs in some circumstances and therefore I think it is better to have it in the users code instead of the component itself as this adds more complexity to the code just for some "small" optimizations. Do you know what I mean?

If you have an example of how you are doing it maybe I can add it to the documentation as a best practice example or something like that.

Then I will close the issue and merge the #57 branch to the master and then release 0.3.1.

Thanks a lot and regards,

Guy