I’m working on an app that is using the JQuery JavaScript framework. Time came for a bit of AJAX long-polling (which I can no longer say without snickering thanks to WebDevGeekly), and so I went looking for a way to do that in jQuery: specifically, I wanted something like Prototype’s Ajax.PeriodicalUpdater, which has a nice decay to pull load off the server if not a lot is changing.
Unfortunately, such a beast doesn’t exist within the core JQuery code. I bitched about the lack of one on Twitter (cite), and ddelponte resisted routing me to http://letmegooglethatforyou.com/?q=jquery+periodicalupdater and instead pointed out the #1 hit on Google: 360innovate’s port.
That port didn’t do quite what I wanted, and I saw a few places to eke efficiencies out of the code, so I did. The new version of the code is hosted at http://github.com/RobertFischer/JQuery-PeriodicalUpdater/. Specific advantages over the 360innovate version are:
- Any option in jQuery’s $.ajax can be used, including any callbacks. The only exception is the flag that treats modifications as errors. That’s always going to be
true(see the next bullet). 304 Not Modifiedpages are now treated like they weren’t modified (that is, timeout increases). Their treatment before was as errors, which caused the timeout to reset to the base value.- The settings passed into the function are now deep-copied, which means the setting object can be mangled after the call without hosing up the entire works.
- As much work as possible is done up front, so the actual polling AJAX call is fairly fast and lightweight. This is important so that it doesn’t clog up the limited resource that is JavaScript user processing threads.
- The first poll begins once the document has finished loading, which should speed initial page load and avoid issues caused by the AJAX response returning before the page is totally rendered.
The code for the PeriodicalUpdater is pretty cool. One stunt which people should definitely pay attention to is using executable code blocks for factoring out loop-invariant checks. In this case, it’s demonstrated in the logic to boost the decay:
// Function to boost the timer (nop unless multiplier > 1) var boostPeriod = function() { return; }; if(settings.multiplier > 1) { boostPeriod = function() { timerInterval = timerInterval * settings.multiplier; if(timerInterval > settings.maxTimeout) { timerInterval = settings.maxTimeout; } }; }
In this case, this behavior is either a nop (for multipliers <= 1), or it's got some involved logic. The 360innovate version did the multiplier check each time the interval was going to be boosted, but that multiplier isn't going to change. Since the multiplier isn't going to change, the code can be factored out and the check can be saved.
The same functionality could be done by the function null unless there is logic attached, but then call points look like this:
if(boostPeriod) boostPeriod();
And I’ll take the overhead of a call to the nop method to get easier-on-the-eyes, more maintainable code.
Related posts:
Pingback: Cry for Help | Enfranchised Mind
Pingback: Updated GORM Labs and JQuery PeriodicalUpdater | Enfranchised Mind
Pingback: New PeriodicalUpdater Feature, and, Mutable Data Sucks: A Case in Point | Enfranchised Mind
Pingback: boncey.org - Machine tags on Flickr
Pingback: Enfranchised Mind » jQuery PeriodicalUpdater Updates
Pingback: Can Has Biz? » Blog Archive » jquery.poll – a periodic polling plugin for jquery.
Pingback: jQuery Rolling and Polling | tips & tricks