Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

Typeahead suggestion list flickers when list comes from remote source #1011

Closed
jamesfm opened this issue Sep 15, 2013 · 7 comments
Closed

Typeahead suggestion list flickers when list comes from remote source #1011

jamesfm opened this issue Sep 15, 2013 · 7 comments

Comments

@jamesfm
Copy link

jamesfm commented Sep 15, 2013

Thanks for all the great work on this project to date. Loving the Angular approach :)

I'm using Typeahead with a remote datasource, retrieving suggestions from a remote service while searches 100,000 items.

I have everything working pretty well, but on every keypress the suggestion list disappears, before reappearing with the results from the remote service.

You can see this behaviour here: http://plnkr.co/edit/eGG9Kj?p=preview (try typing "Little".)

My previous experience has been with JQuery UI autocomplete, which keeps the suggestion list visible and in-place, while the items in the list are replaced with the new suggestions coming from the server - resulting in no flicker and a better experience IMHO.

You can see the jQueryUi behaviour here:

http://jqueryui.com/autocomplete/#remote-jsonp

Thanks for considering this!

@caitp
Copy link
Contributor

caitp commented Sep 15, 2013

I'm not actually seeing the flicker in your example (OSX 10.8.4 / Chrome 29.0.1547.65), for what it's worth. What are you seeing this with?

@jamesfm
Copy link
Author

jamesfm commented Sep 15, 2013

Thanks for fast response! I'm using Chrome 29 on Win7.

On each keypress the list disappears, then returns with the new data. I'm in the UK - perhaps my latency is greater than yours?

@caitp
Copy link
Contributor

caitp commented Sep 15, 2013

I'm not sure, I've just tried again, typing slower, and I do actually get results if I wait a few ms before typing each key.


Looking at the code (in the master branch currently), you should be able to specify a time to wait before the typeahead list is calculated/displayed, with the attribute typeahead-wait-ms -- But testing this in your plnkr I haven't really been successful in making it work.

edit -- Just reallized you're using the 0.2.0 release, which may predate the addition of the typeahead-wait-ms parameter -- Yeah, this feature was added in June, you might want to consider upgrading to a more recent release like 0.4.0


fork -- this has a 500ms wait after the last keypress before displaying the typeahead. This actually feels slightly glitchy, but there is a noticeable delay and would probably reduce flicker a bit. Feels much less glitchy in 0.5.0

@hallister
Copy link

Hmmm... I'm guessing the flicker is caused by the fact that $scope.cities is a promise object until it is resolved, and typeahead isn't aware of that. That's why typeahead-wait-ms won't matter, because there will still be a brief moment where an unresolved promise exists.

I'm not really sure how we'd go about doing this. Not sure of the best way to handle this but maybe wrapping the typeaheadParser.parse(attrs.typeahead); in a $q.when() would do the trick.

@jamesfm
Copy link
Author

jamesfm commented Sep 16, 2013

Thanks for all the helpful thoughts. I'm on the latest 0.6.0 code.

@hall5714 I would agree - I am guessing the list of suggestions is removed on keypress and repopulated once the new cities arrive from the server. If server latency is even moderate, the list disappears and reappears on every keypress.

I don't know how to do this, but I think what's needed is an "in-place" update to an array of objects bound to the relevant bit of dom, so that existing suggestions are added and removed as new data arrives. I guess the alternative (simpler?) is to keep the dom bound to the old data until after the new data is resolved, then update it.

Easy? :)

@hallister
Copy link

@jamesfm Frankly I'm not even sure that's correct. It could be that because the $scope.cities object changes we start over, but I didn't see anything that suggests that's the case.

Regardless, $q.when() would wait for any promises to be resolved before continuing, avoiding having the save state information altogether. Assuming the flicker really is caused by the promise, this would resolve it.

@pkozlowski-opensource
Copy link
Member

@hall5714 @jamesfm yes, this is due to a network time as on each keypress a list is cleared and it makes the popup to hide. But I think that @jamesfm is right we can think of better ways of doing it. The only thing I'm really worried about is that users won't get any visual feedback (as know it is at least clear that there is some work in progress). To be looked into.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants