Prevent stale AJAX data in jQuery

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.

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

Content load on Scroll with jQuery

To produce a similar effect as twitter (although for an entirely different purpose) I created a little bit of script to load additional content to ht end of the document when you scroll to the bottom. This will create the effect of the page being as long as your total content, no page switching, no linking to to other pages, just one long page.

This version uses jQuery because the site I’m making uses jQuery for a bunch of other things, I do have a complete non-jQuery version if anybody is interested. Anyways, heres the code

Snipplr: http://snipplr.com/view/47744/simple-content-load-on-scroll/

The scripts pretty straight forward, only things to note are that the current top display number is stores in a hidden input, the reason I have it set up this way is because if the user doesn’t have jquery, of the script fails to load for some reason, I’ll still know where the are so a traditional next page button will pick up where they left off. There’s also a minor bug on my phone when testing, I’ll look into it and post a fix if I find one, shouldn’t be to hard to fix with some polling (check position every x milliseconds), which, coincidentally is how the non-jQuery version works.

Example can be seen right here: http://fatfolderdesign.com/ex/scroll_load/, it’s as basic as basic can be.

Edit 07/15/2011: Having a problem getting this to work properly in Firefox? So did commenter Mihajlo, he also supplied a fix before I even had a chance to take a look. I talk a little in a new post, aptly names Content load on scroll with jQuery UPDATE but for the short version is add this bit of code, just add it or integrate it into existing code:

Snipplr: http://snipplr.com/view/47744/simple-content-load-on-scroll/

I’ve updated the snipplr post and example page accordingly. Thanks Mihajlo.

Simple Javascript Form Check

This is something I whipped up to make sure people weren’t submitting forms missing vital information, but I didn’t care if the information was wrong. It’s for a back end thing, the general public should be thoroughly checked (it’s a lowest common denominator thing) but if this is an important work related thing your not very likely to mess it up to terribly (but, check for anything that will break your script just in case they do). In this case it was a form that stores client information, if the names in the wrong place it can be edited and it’s not a big deal, but if you really want to ensure accuracy you can run additional checks inside each of the ifs for that articular thing.

Snipplr: http://snipplr.com/view/46271/simple-javascript-form-check/

Two things I’d like to note about this. First, if you have a very large form it should probably be done with a script that looks at all elements instead of using a line per element. Second, you have to make the submit button type="button" instead of type="submit" or you have to make it return true/false upon completion. I don’t see much of an advantage either way so I used a button for simpler testing and never changed it back.