I posted earlier about an ideal I had on preventing stale ajax data from being placed over fresh ajax data, well recently I implemented a simple method of doing this in Query.
Stale ajax data is data that you don’t want anymore. For instance lets say I have a list of cities, say 3000. I want a live filter on this list and I dislike having to press buttons (they are such a bother after all) so I write a script that will load the result filtered for whatever is in my text box every time I release a key in that box, and to keep in all simple I use the onkeyup command.
So I search for “Seattle”, a search is run for “S”, then “Se”, then “Sea” ect ect until I get “Seattle”. Each character is it’s typed. Now there are far more results for that contain “S” then there are that contain “Seattle” so naturally that search will take longer to process*. As such your page will return the “S” result before the “Seattle” result. So the script displays the “Seattle” results, then gets the “S” results and displays them instead, and in so making the search useless.
My initial ideal (even before posting the old post about this) would be to simple compare string sized, since a filter can only make the results smaller, not bigger. Although that in reality is not true, if you type the wrong character and delete it the results could then again be bigger. And the possible solution I posted before is actually a lot more work since it’s passing json variables back and comparing timestamps. This solution is the best I’ve though of, although it too has its downsides.
This solution simply cancels the previous ajax call before making the next one, the following jquery function is ran onkeyup or onkeydown.
|
1 2 3 4 5 6 7 8 9 |
var getting=''; function ajax_get(){ if(getting!=''){getting.abort();} $('#loading_animation').fadeIn(); filter = $.get('/path/to/ajax.file', function(data) { $('#ajax_container').html(data); $('#loading_animation').fadeOut(); }); } |
Snipplr: http://snipplr.com/view/48097/prevent-stale-ajax-data-with-jquery/
The .abort() commands it’s what makes this work, killing off old ajax calls before making new ones. There are some caveats with this method. First, it doesn’t necessarily stop the server from processing the action (although according to the documentation it will try) so the server may keep doing it wasting cpu and ram on nothing. Second, the javascript error console (at least in chrome) sees it has an error when the .abort() happens. This doen’t cause any problems to the end user but can ugly up the console. I’d would guess though that the only people who would bother to look at the console are other programmers (because a non-programmer wouldn’t know exactly whats going on and it’s of no help to them) and they’ll be able to look at the code and see that it’s not truly an error. If you are uncomfortable with running the script with those problems theres always my previous ideal, it should be error free (but it’s all a theory I never put to use).
There’s no example for this one (although if requested I can make one).
* A simple single table search for names on even a large database would probably not have a problem, searching with a more complicated query across multiple databases and post processing those results both slow down the response and are far more common in my experience, especially since I usually don’t return json or XML but pre formatted ready to post HTML. This has the added advantage of (if properly set up) only requiring 1 script to call the data for both the initial load and any ajax loads, making future changes all the faster