Concurrency issues with find-as-you-type boxes
Find-as-you-type boxes are usually built by observing changes in a text field, and querying the server via AJAX for search results or suggestions when the field has changed.
A common problem with this implementation is that there is no guarantee that AJAX responses are evaluated in the same order as the original requests. The effect for the user is that the search results are flashing back and forth while the user is typing the query, and when the user has stopped typing the last results don't always match the final query.
You won't notice this effect while developing on a local development server like Webrick, which processes requests one at a time. You will however notice the effect after deploying on a production server with multiple concurrent worker processes. Consider using Passenger in development instead.
Workarounds
- An dirty solution for small applications is to make the observe frequency low enough that out-of-order responses become unlikely enough. Try to poll the query field for changes every 0.75 seconds or longer. It will still fail when the server is busy or on flakey connections.
- A cleaner solution would be to check whether a response contains the matches for the most recent request, and discard all other responses.
- Or have a client-side queue so you don't send multiple requests at the same time. If you're using
Unpoly
Archive
,
up.observe()
Archive orup.autosubmit()
Archive will do this for you. - If you make the request yourself you may also choose to
abort an earlier XHR request
Archive
. You may also
abort
fetch()
requests Archive .
Your development team has a full backlog of feature requests, chores and refactoring coupled with deadlines? We are familiar with that. With our "DevOps as a Service" offering, we support developer teams with infrastructure and operations expertise.