Debounce isn't working correctly

[cnanney]

On the examples page:
http://twitter.github.com/typeahead.js/examples/

Go down to the Best Picture Winners and open the network inspector. Type in 'all' and see one remote request made to all.json. If you quickly hit backspace three times to clear the input, a second request should not be made, but one is made to al.json.

Chrome 26.0.1410.43 m

[jharding]

As weird as it may seem, this is actually working as expected. The behavior your seeing is caused by the following 2 implementation details:

• Remote requests are only made when there aren't enough suggestions available in local and prefetch.
• Transport#get is the function called when remote requests are needed and it is rate-limited.

Once you start backspacing from all, this is what happens:

1. Backspace.
2. The query is now al, prefetch suggestions are rendered.
3. There aren't enough prefetch suggestions, so Transport#get is called with al.
4. Backspace.
5. The query is now a, prefetch suggestions are rendered.
6. There are enough prefetch suggestions, so Transport#get is not called.
7. The debounce wait interval has passed, and since Transport#get was last called with al, a request is made for al.

Hopefully I did an ok job explaining this, if you have any follow-up questions let me know.

[cnanney]

Thanks for the explanation, I thought the debounce was basically just resetting a 300ms timeout every keypress, and once the timeout is able to expire, send a query with the current input value.

Would step 7 of your explanation make more sense to check if al was still the input value before sending off a request?

[jharding]

Would step 7 of your explanation make more sense to check if al was still the input value before sending off a request?

Yep, this would make a lot more sense. I'm going to use this issue to track that change.

[Jellyfrog]

Wouldn't it be more logical to just do a clearTimeout() at every keystroke if the setTimeout exists? Rather than checking the vaules match? Or am I missing something here?

[jharding]

Doing a clearTimeout after each keystroke would work, however with how things are currently implemented, checking to see if the input value has changed would be easier.

[twhitbeck]

I'm running into this issue, or something like it. Things have changed now with Bloodhound being its own component.

My issue:
Rate limiting works perfectly for remote requests until you type in a query that was already requested, and there's an entry in the in-memory request cache. When you do this, a remote request is made with the query that was submitted immediately prior to the current query.

The sequence of events is like this (with debounce rateLimit fn):

1. bloodhound.get('t') -> transport.get('t') -> transport._get('t')
2. bloodhound.get('te') -> transport.get('te') -> transport._get('te')
3. bloodhound.get('tes') -> transport.get('tes') -> transport._get('tes')
4. bloodhound.get('test') -> transport.get('test') -> transport._get('test')
5. wait
6. rate limited transport._get('test') goes through
7. bloodhound.get('tes') -> transport.get('tes') -> transport._get('tes');
8. bloodhound.get('test') -> transport.get('test') -> hit requestCache
9. wait
10. rate limited transport._get('tes') goes through

In the event that we hit the requestCache, the rateLimited request can be cancelled. Not exactly sure how to go about it, though (since rateLimit can be debounce, throttle, or even custom)

[jharding]

Fixed for v0.10.3.