JQuery_ Novice to Ninja - Earle Castledine [75]
Chapter 6
Construction, Ajax, and Interactivity
Throughout the preceding chapters we’ve wowed and dazzled our client with a cornucopia of visual effects and optical magic tricks, giving his site a lifelike appearance. Unfortunately, our client is becoming savvy: as well as wanting his pages looking Web 2.0, he wants them acting Web 2.0 as well. And having pages act Web 2.0 means one thing: Ajax!
And not just a little bit—he wants the works: inline text editing, Twitter widgets, endlessly scrolling image galleries … he wants StarTrackr! to have more Ajax-enabled bells and whistles than Facebook, Flickr, and Netvibes combined.
That’s fine by us. Implementing client-side Ajax functionality is easy, especially with jQuery as our framework. But these cool new features come at a cost of increased complexity. Some simple tasks (such as loading in a snippet of HTML) are no problem—but as we start to tackle the business of creating advanced Ajax components, the risk of making a mess of unmaintainable spaghetti code grows large. So before we jump into the deep end, we’ll review some ways we can manage complexity, and write well-behaved code that will impress our peers.
Construction and Best Practices
JavaScript is a wonderful language. Don’t let anyone tell you any different. Its historically poor reputation stems from years of misunderstanding and misuse: an almost infinite collection of inline scripts, displaying little regard for good coding practices like encapsulation and reuse. But the past few years have ushered in a new era for this underdog of the Web. Developers have begun to respect (and conquer) the language, and the result has been some great code libraries—including our favorite, jQuery.
jQuery has greatly simplified the process of dealing with Ajax and the DOM, but it hasn’t changed the benefits of writing nice clean JavaScript code. There’s no need for us to become masters of JavaScript—but there are a few steps we should take to ensure we’re writing the kind of code that will make future developers and maintainers of our projects want to buy us a beer.
Cleaner jQuery
We’ve done a fairly good job of steering clear of any involved JavaScript code—that’s a testament to how good jQuery is at doing what it does. But as our jQuery components and effects grow more complex, we need to start thinking about how to best structure our code. Once again we should remember that, under the hood, jQuery is just JavaScript—so it’ll serve us well to steal a few best practices from the world of JavaScript. We already saw a bit of this kind of code organization when we built our advanced tooltip script at the end of Chapter 5. Now let’s reveal the whys and hows of writing cleaner jQuery code.
Code Comments
Just like HTML and CSS, JavaScript provides you with a way to comment your code. Any line that you begin with two slashes (//) will be ignored by the browser, so you can safely include explanations about what your code is doing. For example, in this snippet the first line will be ignored, and only the second will be processed as code:
// Assign the value '3' to the variable 'count':
var count = 3;
If you need to write comments which stretch over multiple lines, you can begin them with /* and end them with */. For example:
/* An example of
a multiline
comment
*/
var count = 3;
Comments go a long way to making your code reusable and maintainable: they help you see at a glance what each line or section is doing when you revisit code you wrote months ago.
Map Objects
We’ve been dealing with key/value pair objects since all the way back in Chapter 2. We use them to pass multiple options into a single jQuery action, for example:
$('p').css({color:'green', padding:'3px'});
They aren’t special jQuery constructs—once again, it’s just plain old JavaScript—but they’re great for encapsulating data to pass around in your own functions and widgets. For example, if you pull data out from some form fields, you can package them up into key/value mapped pairs that you can then process further: