Because jQuery is a well-written modular framework, it’s easy to treat it as a black box. But, it’s instructive to look at the underlying code, and see how the nuts and bolts go together. If you’re interested, as of jQuery 1.3, the selector engine is now based on a separate project by John Resig, called sizzle, and offers several performance enhancements over the previous method for selecting elements. See http://sizzlejs.com for more.
If you recall from Chapter 2, a self-invoking anonymous function looks like this:
(function(arguments){
// do something
})();
jQuery is also a self-executing anonymous function, which accepts two arguments — the window object and undefined:
(function( window, undefined)
{…} // definition of core
) (window);
The window object is passed in as a small performance boost. For any call to the global window object inside the jQuery function definition, instead of looking up the definition of the window in the global context, it looks inside the local context avoiding one step in the lookup. It’s small, but does represent an improvement.
At first, it might seem a little baffling to pass in undefined, but there is a good reason. The undefined built-in type is assignable. So, conceivably, someone on your development team could do something like undefined = true; and then your comparisons won’t work as expected. (Paul Irish has a special term for team members like this; see his video on “10 Things I Learned from the jQuery Source” at http://paulirish.com/2010/10-things-i-learned-from-the-jquery-source/.)
Looking further down in the code, you can see how the utility methods are added to the jQuery function:
…
jQuery.extend({
noConflict: function( deep ){
…
isFunction: function( obj ){
…
isArray: Array.isArray || function( obj ){
…
The jQuery function is .extend()-ed with an object literal, with key-value pairs of method names to method definitions, as you can see from the previous snippet taken from jQuery source. Looking through the method definitions you can see exactly how the comparisons are done, and what each method expects.
Our favorite lesson from looking at the source is how the $.ready() works. There isn’t an .onReady() event in the DOM. Again, looking at the source code is instructive:
// The DOM ready check for Internet Explorer
function doScrollCheck() {
if ( jQuery.isReady ) {
return;
}
try {
// If IE is used, use the trick by Diego Perini
// http://javascript.nwbox.com/IEContentLoaded/
document.documentElement.doScroll(“left”);
} catch(e) {
setTimeout( doScrollCheck, 1 );
return;
}
// and execute any waiting functions jQuery.ready();
}
// Expose jQuery to the global object return jQuery;
…
.ready() executes when all of the DOM elements are loaded, but not necessarily all parts of the page, such as images or Flash files. At this point, it’s nice to have the capacity to manipulate the DOM at once. The JavaScript method .doScroll() throws an exception when you try to run it and the DOM isn’t loaded. The call to doScroll() is wrapped around a try/catch statement. When an exception occurs (while the DOM elements are loading), the doScrollCheck() method calls itself recursively, until the DOM is fully loaded. At that point, doScroll stops causing an exception, and jQuery then executes the code bound to .ready().
This section is very small, and doesn’t really do justice to all of the powerful coding techniques used in jQuery. But, we highly recommend that you look through it, and apply the ideas to your own projects.
Source: Otero Cesar, Rob Larsen (2012), Professional jQuery, John Wiley & Sons, Inc