Scriptble » jQuery

jQuery ready, delegate, live!

JC Fant IV — Wed, 09 Mar 2011 18:18:51 +0000

Recently I was browsing through the jQuery subr reddit and noticed this question pop up. Since I am sure this is a pretty common question on "Why won't my jQuery command work properly", I figured I would give a shot at answering it.

Hey guys, I'm sure this has been answered before but I can't seem to find anything by searching Google or /r/jquery. I am a beginner with this so forgive me, but I can't find an explanation to this anywhere and I'm curious. When I try to stop the default submit function of a form in the tag of a .html file it won't work, but when I copy and paste the same code into the it works fine. Regardless of where I place it, it is always below the link to the jquery library. This is really confusing and I was hoping you guys could explain this for me. Thanks! via jQuery

However, if he moved the

Why?

Why on earth would the first one work, and the second one not? Well, it comes down to when the dom is ready. In the second example, jQuery is looking for a form tag that hasn't been parsed by the browser yet. So it returns an empty jQuery object, to which the submit event is attached.

The Fix

We have a couple of ways of fixing this issue.

.ready()

The .ready() event attached to the BODY tag, will allow us to attach the submit event as soon as the DOM is ready
$(document).ready(function() { $("form").submit(function() { return false; }); })

.delegate()

The .delegate() method can be placed anywhere in your page. Since the delegate function will attach the event to any current "form" elements, or any future "form" elements that may appear in the DOM. The gotcha... If you only have one form element on the page, this will work fine. However, IF for some reason, you create another form element, this same event will be attached to that form as well.
$(document).delegate("form", function() { $("form").submit(function() { return false; }); })

.live()

The .live() method is a variation/alternative of the .delegate() method. However, at least one element must exist before you can use it. Which means, you still need to wrap it in a .ready() or put it in the footer.

This method is a variation on the basic .bind() method for attaching event handlers to elements. When .bind() is called, the elements that the jQuery object refers to get the handler attached; elements that get introduced later do not, so they would require another .bind() call.
$(document).ready(function() { $("form").live("submit", function() { return false; }); })

In all, either .ready() or .delegate() will work, just make sure you use them properly. You don't want to add another form or other element and have it get an event you hadn't planned on.

Writing and Updating DOM Elements in a Frame

JC Fant IV — Thu, 17 Feb 2011 00:30:45 +0000

Handling writing and updating objects in an iframe can be bothersome in most browsers. Sure things like jQuery tend to help, but not always.

A normal way to access a frame in jQuery is below:


	$("#FRAME").contents()

Now, lets say you actually want to get another element inside of the frame, lets get the HEAD element.


	$("#FRAME").contents().find("HEAD");

Awesome, we now have the head element of the document in the frame. Lets add a style tag to it.


	$("#FRAME").contents().find("HEAD").append('');

Now this worked in most browsers... I say most for a reason. This was an actual use case I was trying to accomplish. However, good ole' IE wouldn't let me actually add a DOM element anywhere in the frame. The only thing I was able to do was to add in style tags on the elements. So how did I get around it?


	var ifrm;
		
	function addElementToFrame(newStyle) {
		if (typeof ifrm == "undefined"){
			ifrm = document.getElementById('previewFrame');
			if (ifrm.contentWindow){
				ifrm = ifrm.contentWindow;
			}else{
				if (ifrm.contentDocument.document){
					ifrm = ifrm.contentDocument.document;
				}else{
					ifrm = ifrm.contentDocument;
				}
			}
		}
		
		/*
		 * Now that we have the document, lets add a new style tag
		 */
		$("HEAD", ifrm.document).append("");
		
	}

Wow, interesting mix of using straight JavaScript and jQuery in there. However, what happens when I want to just update the same style tag with something new?


	var ifrm;
		
	function addElementToFrame(newStyle) {
		if (typeof ifrm == "undefined"){
			ifrm = document.getElementById('previewFrame');
			if (ifrm.contentWindow){
				ifrm = ifrm.contentWindow;
			}else{
				if (ifrm.contentDocument.document){
					ifrm = ifrm.contentDocument.document;
				}else{
					ifrm = ifrm.contentDocument;
				}
			}
		}
		
		/*
		 * Now that we have the document, look for an existing style tag
		 */
		var tag = ifrm.document.getElementById("tempTag");
		
		/*
		 * Hmm, this doesn't look right, but it is. IE will not allow you 
		 * to use a pre-existing style tag and set the innerHTML for that 
		 * element. Which means, we can't create the style tag in another
		 * function and pass back the element and then set the innerHTML 
		 * to what we need. Plus, with this limitation, now we need to 
		 * actually remove the style element from the DOM and recreate 
		 * it each time. LAME.
		 */
		if (typeof tag != "undefined" || tag != null){
			$("#tempTag", ifrm.document).remove();
		}
		
		/*
		 * We only have one shot at writing out the style tag, we must 
		 * include the css at that point as well or IE will bail with an
		 * unsuported method exception.
		 *
		 * add a new style tag
		 */
		$("HEAD", ifrm.document).append("");
	}

And that is how you can add new elements to a DOM in an iframe inside of your page.

Expanding the jQuery Plugin Development Pattern

JC Fant IV — Tue, 15 Feb 2011 01:00:25 +0000

Doing research on a recent project, I came across an article by Mike Alsup on a "jQuery Plugin Development Pattern". If you haven't seen it already its worth a trip to learningjquery.com to checkout the implementation of his pattern.

"There are a few requirements that I feel this pattern handles nicely:"

Claim only a single name in the jQuery namespace

Accept an options argument to control plugin behavior

-Provide public access to default plugin settings-

Provide public access to secondary functions (as applicable)

Keep private functions private

Support the Metadata Plugin

Allow for extending the object via callbacks (either hooks or events) as applicable

Scope all selectors with the 'this' object

This is a great start to "authoring a jQuery plugin":http://docs.jquery.com/Plugins/Authoring. However, there are a couple more requirements that I would propse adding in.

Claim only a single name in the jQuery namespace
Accept an options argument to control plugin behavior
-Provide public access to default plugin settings-
Provide public access to secondary functions (as applicable)
Keep private functions private
Support the Metadata Plugin
**Allow for extending the object via callbacks (either hooks or events) as applicable**
**Scope all selectors with the 'this' object**

So lets take a look at how we can implement this pattern using a tab plugin.

Claim Only a single name in the jQuery namespace

Setting up a new plugin is pretty simple. First we need to add the plugin name to the jQuery.fn namespace.


	;(function($){
	})(jQuery);

Notice that We scope the setup of this plugin inside of an anonymous function that executes with the jQuery parameter as $. We do this so that the jQuery namespace can be changed in order to play well with other javascript frameworks. It also allows us to scope jQuery to $ incase the namespace has already been changed.

Next we need to setup the single namespace for our plugin.


	;(function($){
	    $.fn.tabs = function(tabOptions) {
	        // support mutltiple elements
	        if (this.length > 1){
	            this.each(function() { $(this).tabs(tabOptions) });
	            return this;
			}
        }
	})(jQuery);

Notice we setup the name of our plugin into the jQuery.fn namespace. Also, we add in a bit of trickery. We need to make sure that if this plugin is called on multiple DOM elements, that it will still function properly. We do this by looping through each of the elements and calling .carousel() on them. We then return "this" in order to allow chaining of methods.


        // support mutltiple elements
        if (this.length > 1){
            this.each(function() { $(this).tabs(tabOptions) });
            return this;
		}

Accept an options argument to control plugin behavior

By creating an options argument, we can allow the users to expand/change the default behavior of the plugin. The following code adds in a newOptions parameter and then uses jQuerys built in $.extend to override the default plugin options.


	;(function($){
    $.fn.tabs = function(tabOptions) {
        // support mutltiple elements
        if (this.length > 1){
            this.each(function() { $(this).tabs(tabOptions) });
            return this;
        }

        // SETUP private variabls;
        var tabs = this;

        // setup options
        var defaultOptions = {
								//default options go here.
                                };
								
        var options = $.extend({}, defaultOptions, tabOptions);

        return this;
    }
})(jQuery);

Notice the following code it expands the default options:


        var options = $.extend({}, defaultOptions, tabOptions);

Provide public access to secondary functions (as applicable)

We can give access to public functions by attching the functions to the magic variable "this".


	;(function($){
	    $.fn.tabs = function(tabOptions) {
	        // support mutltiple elements
	        if (this.length > 1){
	            this.each(function() { $(this).tabs(tabOptions) });
	            return this;
	        }
	
	        // SETUP private variabls;
	        var tabs = this;
	
	        // setup options
	        var defaultOptions = {
	                                    debug : false
	                                };
	        var options = $.extend({}, defaultOptions, tabOptions);


			// PUBLIC functions
	        this.changeTab = function() {
	            // change Tab
	        };
	
	        this.getOptions = function() {
	            return options;
	        };

	
	        return this;
	    }
	})(jQuery);

Keep private functions private

Private functions setup in the way below can only be called from within the scope that they were created. What this means is that there is no outside access to these functions. They can only be called from within another public methods or another private methods. In order to access this data we would need to setup public methods to call these private methods.


	;(function($){
	    $.fn.tabs = function(tabOptions) {
	        // support mutltiple elements
	        if (this.length > 1){
	            this.each(function() { $(this).tabs(tabOptions) });
	            return this;
	        }
	
	        // SETUP private variabls;
	        var tabs = this;
	
	        // setup options
	        var defaultOptions = {
	                                    debug : false
	                                };
	        var options = $.extend({}, defaultOptions, tabOptions);

	        // SETUP private functions;
	        var intialize = function() {
					return tabs;
	        };
			
	        var findTabs = function() {
	                                // do something .
	                            };
								
			var selectTab = function(element, tabCSS, selectedClass){
									// do something .
								};
								
	        var hooks = function() {
	                                // do something .
	                            };
			
			// PUBLIC functions
	        this.changeTab = function() {
	            // change Tab
	        };
	
	        this.getOptions = function() {
	            return options;
	        };
	
	        return intialize();
	    }
	})(jQuery);

Support the Metadata Plugin

Supporting the Metadata plugin is fairly trivial. We test for the existence of the plugin and then add the data that would be attached to the element.


	;(function($){
	    $.fn.tabs = function(tabOptions) {
	        // support mutltiple elements
	        if (this.length > 1){
	            this.each(function() { $(this).tabs(tabOptions) });
	            return this;
	        }
	
	        // SETUP private variabls;
	        var tabs = this;
	
	        // setup options
	        var defaultOptions = {
	                                    debug : false
	                                };
	        var options = $.extend({}, defaultOptions, tabOptions);

	        // SETUP private functions;
	        var intialize = function() {
	                // support MetaData plugin
	                if ($.meta){
	                    options = $.extend({}, options, this.data());
	                }

					return tabs;
	        };
			
	        var findTabs = function() {
	                                // do something .
	                            };
								
			var selectTab = function(element, tabCSS, selectedClass){
									// do something .
								};
								
	        var hooks = function() {
	                                // do something .
	                            };
			
			// PUBLIC functions
	        this.changeTab = function() {
	            // change Tab
	        };
	
	        this.getOptions = function() {
	            return options;
	        };
	
	        return intialize();
	    }
	})(jQuery);

Allow for extending the object via callbacks (either hooks and/or events)

In order to do this, lets take a more in depth look at the changeTab function. It sounds complicated, however its a trivial task to setup and allow the moveSlider functionality to be altered by the external options.


	// PUBLIC functions
    this.changeTab = function() {
        // change Tab
    };

In order to alter the behavior we need to allow the user to pass in some options.


    // setup options
    var defaultOptions = {
								beforeLoad : function() {
												// do something .
											},
								afterLoad : function() {
												// do something .
											},
                                debug : false
                            };

Now, lets update hooks function to see what needs to be done in order to call the function.

	   
        var hooks = function(thisObject, hookList, triggerName){
            $(presentation).trigger(triggerName, thisObject);
            if ($.isFunction(hookList)){
                return hookList.apply(thisObject, []).isOK;
            } else if ($.isArray(hookList)) {
                var result = {
                    isOK: true
                };
                for (var i = 0; i < hookList.length; i++) {
                    if (result.isOK) {
                        result = hookList[i].apply(thisObject, [ result.data ]);
                    }
                }
                return result.isOK;
            }else{
                return true;
            }
        }

What exactly is this doing? First of all the hooks function takes 3 parameters. thisObject is equal to the object that you want the callback function to have "this" set to, a method to call back on called hookList and the name of the event to be triggered. The reason we call it list, is that we will check to see if hookList is an array of functions or just a single function. The following call passes in the tabs object and the onstart callbacks.

Now, lets change the this.changeTab to make use of the beforeLoad and afterLoad events.


	this.changeTab = function(element){
		if (hooks(tabs, options.beforeLoad, "beforeLoad")){
			selectTab(element, options.tabsClass, options.tabsSelected);
			
			var tabOptions = {};
			if (options['tab' + tabs.mainTab] != undefined) {
				tabOptions = options['tab' + tabs.mainTab];
			}
			
			$(options.tabPanels, this).hide();
			
			if (options.afterLoad != undefined) {
				hooks(tabs, options.afterLoad, "afterLoad")
			} else {
				$('.tab' + tabs.mainTab, this).show();
			}
		}
	};

In the hooks method we use the .apply in order to pass "this" as the plugin to the next function. They will have access to all of the public methods that are on that instance of the tabs plugin.

Scope all selectors with the 'this' object

This is actually really simple, but will control the scope of the objects returned by jQuery. Without this, you may clobber another widget on the page or jump outside of the element you are working on. Lets take another look at the selectTab method and see how we can scope our selectors.


         var selectTab = function(element, tabCSS, selectedClass){
              var selectedTab = 0;
              selectedClass = selectedClass.replace(/^./, "");
              $(tabCSS).each(function(){
                   if (this == element) {
                        tabs.mainTab = selectedTab;
                        $(element).addClass(selectedClass);
                   } else {
                        $(this).removeClass(selectedClass);
                   }
                   selectedTab++;
              });
         };

On the surface, there is nothing wrong with this. However, what happens if we have two different tab groups on the page? Nothing? How about an extremely large DOM? Would this slow down? Yes, actually it would and you may or may not be acting on a set of tabs that aren't your own.

So how do we fix this?


         var selectTab = function(element, tabCSS, selectedClass){
              var selectedTab = 0;
              selectedClass = selectedClass.replace(/^./, "");
              $(tabCSS, tabs).each(function(){
                   if (this == element) {
                        tabs.mainTab = selectedTab;
                        $(element).addClass(selectedClass);
                   } else {
                        $(this).removeClass(selectedClass);
                   }
                   selectedTab++;
              });
         };

Wait, that is the same code? Close, but look closer at the $(tabCSS) selector. Notice, we now use $(tabCSS, tabs). (You could also use $(tabs).find(tabCSS); is faster in most browsers). This limits the scope of the search for the tabs and it won't clobber any other tab widgets on the page.

jQuery 1.5 Deferreds

JC Fant IV — Sun, 13 Feb 2011 02:59:18 +0000

Eric Hynds on his blog the other day gave a very good run down of jQuery 1.5 Deferreds. From the post:

Deferreds, new in jQuery 1.5, decouple logic dependent on the outcome of a task from the task itself. They’re nothing new to the JavaScript scene; Mochikit and Dojo have implemented them for some time, but with Julian Aubourg’s AJAX rewrite landing in 1.5, deferreds in jQuery was the logical next step. With deferreds, multiple callbacks can be bound to a task’s outcome, and any of these callbacks can be bound even after the task is complete. The task in question may be asynchronous, but not necessarily.

Especially nice is being able to couple multiple statements and once they finish being able to go on to the next step.

In the following example, we retrieve JSON data and a separate template, once the calls finish we move onto rendering them using Underscore.js templating.


var JSONData = {};
var template = "";
function loadData(data){
     JSONData = data;
}

function loadTemplate(data){
     template = data;
}

function render {
     var output = _.template(template, { employeeList : employeeList } );
     $(document.getElementById("output")).html(output);
}

$.when(
     $.getJSON("JSONData").success(loadData), 
     $.get("template.tmpl").success(loadTemplate)
).then(
   render
);

Deferreds in jQuery is step in the right direction and adds in some very nice functionality to an already feature rich library.

$(“#ID”) is fast enough

JC Fant IV — Sat, 12 Feb 2011 22:22:38 +0000

We all know that the fastest selector to use is the ID. Something like $("#id") is better than using a class. However, after looking at the last test we did on The Great Assumption - JavaScript I noticed a large discrepancy in $("#ID") versus the native document.getElementById().

Now, I always assumed it was slower, but not anywhere near close to what I saw. So, lets challenge the assumption that $("#ID") is good enough.

Setting up the Test

You can see the test here: JSPerf $(doc.getElementById()) versus $("#id")

I wanted to test 3 of the latest versions of jQuery, same as the last test. I added the following to the test:

The Tests

So lets setup the actual tests:


		//getElement - 1.4.2
		$142(document.getElementById("button"));
		
		//ID - 1.4.2
		$142("#button");
		
		
		//getElement - 1.4.4
		$144(document.getElementById("button"));

		//ID - 1.4.2
		$144("#button");
		
		//getElement - 1.5
		$15(document.getElementById("button"));
		
		//ID - 1.4.2
		$15("#button");

Each one of the tests above will run and the result will be returned in Ops/Sec.

Results

After runs in all different versions of the browsers we have a fairly good idea of the results. Take a look below.

Native Browser Call Results

From the last test we know that getting a Node Element from the native browser call is suprisingly efficient and fast in many browsers. Well, that is unless you are using IE 6, 7, 8 or even the beta 9.

jQuery $("#ID") Results

The results from this test show that getting an ID using jQuery is much faster than using the class selector. However, it is way behind the native call. The root cause of this is actually due to how the init function is configured. Looking at the source for 1.5, an ID selector will hit 6 IF statements, plus 1 regex before it makes the native document.getElementByID(). After the call, there is a series of browser compatibility checks before it assigns the Node Element to the jQuery object and returns.


init: function( selector, context ) {
	var match, elem, ret, doc;

	// Handle $(""), $(null), or $(undefined)
	if ( !selector ) {
		return this;
	}

	// Handle $(DOMElement)
	if ( selector.nodeType ) {
		this.context = this[0] = selector;
		this.length = 1;
		return this;
	}
	
	// The body element only exists once, optimize finding it
	if ( selector === "body" && !context && document.body ) {
		this.context = document;
		this[0] = document.body;
		this.selector = "body";
		this.length = 1;
		return this;
	}

	// Handle HTML strings
	if ( typeof selector === "string" ) {
		// Are we dealing with HTML string or an ID?
		match = quickExpr.exec( selector );

		// Verify a match, and that no context was specified for #id
		if ( match && (match[1] || !context) ) {

			// HANDLE: $(html) -> $(array)
			if ( match[1] ) {
				doc = (context ? context.ownerDocument || context : document);

				// If a single string is passed in and it's a single tag
				// just do a createElement and skip the rest
				ret = rsingleTag.exec( selector );

				if ( ret ) {
					if ( jQuery.isPlainObject( context ) ) {
						selector = [ document.createElement( ret[1] ) ];
						jQuery.fn.attr.call( selector, context, true );

					} else {
						selector = [ doc.createElement( ret[1] ) ];
					}

				} else {
					ret = jQuery.buildFragment( [ match[1] ], [ doc ] );
					selector = (ret.cacheable ? ret.fragment.cloneNode(true) : ret.fragment).childNodes;
				}
				
				return jQuery.merge( this, selector );
				
			// HANDLE: $("#id")
			} else {
				elem = document.getElementById( match[2] );

				// Check parentNode to catch when Blackberry 4.6 returns
				// nodes that are no longer in the document #6963
				if ( elem && elem.parentNode ) {
					// Handle the case where IE and Opera return items
					// by name instead of ID
					if ( elem.id !== match[2] ) {
						return rootjQuery.find( selector );
					}

					// Otherwise, we inject the element directly into the jQuery object
					this.length = 1;
					this[0] = elem;
				}

				this.context = document;
				this.selector = selector;
				return this;
			}

		// HANDLE: $("TAG")
		} else if ( !context && !rnonword.test( selector ) ) {
			this.selector = selector;
			this.context = document;
			selector = document.getElementsByTagName( selector );
			return jQuery.merge( this, selector );

		// HANDLE: $(expr, $(...))
		} else if ( !context || context.jquery ) {
			return (context || rootjQuery).find( selector );

		// HANDLE: $(expr, context)
		// (which is just equivalent to: $(context).find(expr)
		} else {
			return jQuery( context ).find( selector );
		}

	// HANDLE: $(function)
	// Shortcut for document ready
	} else if ( jQuery.isFunction( selector ) ) {
		return rootjQuery.ready( selector );
	}

	if (selector.selector !== undefined) {
		this.selector = selector.selector;
		this.context = selector.context;
	}

	return jQuery.makeArray( selector, this );
},

Notice the elem = document.getElementById( match[2] ) on line 58. This is the part where it delegates its call to the native function.

HOWEVER, what is that on line 9? A use case for $(DOMElement)? Why yes, yes it is, and that leads us to the next test.

Hybrid Results

So by selecting the DOM Element, and passing it into to jQuery we have achieved nearly 100% or more increase in speed across all browsers (except IE). IE still benefits from this method, it had a 49% increase in operations per second.

Hybrid Results

Here you can clearly see that by using a hybrid solution we have achieve a significant amount of gain over using the built in jQuery ID selector. Its not nearly as fast, but allows us to benefit from the built-in functions of jQuery and speed up the operation.

Do This, Not That

Not exactly what I expected when I set out on this one. However I think we have a clear winner. IF you are using jQuery, pass the node Element in, other wise just use the native getElementById().

Conclusion

Do This


		$(document.getElementById("someId"));

Not That


		$("#someId");

The Great Assumption – Javascript

JC Fant IV — Fri, 11 Feb 2011 04:52:28 +0000

A couple of weeks ago I was sitting down with a Google Frontend Engineer friend of mine, talking about some of the JavaScript best practices we all have come to know and abide by. I found myself in agreement with 90% of everything we were talking about. However, something kept eating at me. Why do we both agree on these things? Is it because we actually sat down and did some test? Or is more because early in our careers we were told it was the correct way and have never gone about challenging our assumptions.

So with this post, I am going to start challenging our assumptions on what's right, OR validate those assumptions with some documented proof. Thus begins our first in a series of posts about performance, and a "Do this, Not that" series. Some of the posts will focus on jQuery, others on core JavaScript, however all of them should give you some insight on what to do in the future.

Find Versus Context

Everyone has heard that we should scope our requests in jQuery to make sure and only return results that we are looking for. This is especially true if we are writing a plugin. And lately I have been hearing we should be using .find() to get the elements we are looking for.

Of course, that peaked my interest. Why use .find() which I had heard was slower, than using $("", context) which scopes the call in much the same way in jQuery. So I set off to write a Performance Test that would check to see which one I should be using.

Setting up the Test

You can see the test here: JSPerf jQuery Find Versus Context versions 1-4-2 to 1-5

I wanted to test 3 of the latest versions of jQuery, plus the browsers native docuemnt.getElementById(). so I added the following to the test:

Notice that I am going to set a variable for each of the individual jQuery versions. This allows me to use multiple version in the noConflict() state. (They won't overwrite each other and I will be able to have all of them on the same page.) Also, I setup a couple of variables that I want to cache the results. If we had to call this for each of the tests, we wouldn't get an accurate result between a find and context search.

The Tests

So lets setup the actual tests:


	//Get - document
	var item = document.getElementById("button");

	//Get - ID 1.4.2
	var item = $142("#button");

	//Get - ID 1.4.4
	var item = $144("#button");

	//Get - ID 1.5
	var item = $15("#button");

	//Context - ID 1.4.2
	var item = $142("#button", context42);

	//Context - ID 1.4.4
	var item = $144("#button", context44);

	//Context - ID 1.5
	var item = $15("#button", context5);

	//Find - ID 1.4.2
	var item = context42.find("#button")

	//Find - ID 1.4.4
	var item = context44.find("#button")

	//Find - ID 1.5
	var item = context5.find("#button")

	//Get - Class 1.4.2
	var item = $142(".buttonRef");

	//Get - Class 1.4.4
	var item = $144(".buttonRef");

	//Get - Class 1.5
	var item = $15(".buttonRef");

	//Context - Class 1.4.2
	var item = $142(".buttonRef", context42);

	//Context - Class 1.4.4
	var item = $144(".buttonRef", context44);

	//Context - Class 1.5
	var item = $15(".buttonRef", context5);

	//Find - Class 1.4.2
	var item = context42.find(".buttonRef")

	//Find - Class 1.4.4
	var item = context44.find(".buttonRef")

	//Find - Class 1.5
	var item = context5.find(".buttonRef")

Each one of the tests above will run and the result will be returned in Ops/Sec. At this point, we are going to run a test to figure out how fast a context.find(""), $("", context) take for an ID and for a class. I also added in a default document.getElementById() to test how fast natively the browser is able to get a Node Element.

Results

After runs in all different versions of the browsers we have a fairly good idea of the results. Take a look below.

Find a class element Results

In General this test held true. Using find in all but FF3 and Opera is a faster way to find an element using a class.

Conclusion

Do This


		context.find(".someclass");

Not That


		$(".someclass");

Find an element by ID Results

WOW, not what I expected. Not one browse was a find faster than just using $("#someID"). Basically this all boils down to how jQuery treats an ID selector. It doesn't use the sizzle engine to query the Node Element, but uses the browsers built in document.getElementById(). However, if you pass in a context jQuery will use the engine to make sure the element falls within the context you are using.

Conclusion

Do This


		$("#someID");

Not That


		context.find("#someId");
		$("#someId", context);

Find an element using built in getElementById() Results

Ok, so this result really confused me after seeing the jQuery $("#someID") results. I wasn't expecting there to be such a discrepancy in operations per second. After seeing this result, I actually started putting together another post. Which will end up the second part of this series.

It should be noted that Chrome, Opera, Safari and FF are all doing well over a million operations per second in this area.

IE breakdown

After seeing the results above, I thought we needed one more graphic showing the extremely bad numbers IE put up in this test. There was no noticable change between IE6 and IE7, and while IE8 is better, its still bad. However, it looks like the IE9 team is finally taking web development seriously and trying to make some improvements. Of course those improvements still fall WAY short of any of the other browsers on the market.

Come on IE team, haven't we learned anything from the IE6 debacle?

Conclusion

Overall, the conlusion here is to never use a context based find/search for an ID. (since there is always only one on the page... right?) If you need to get an element using an ID, just call it via $("#someID").

IF you need to get a class element(s), follow this rule:
context.find() > $(".someClass", context) > $(".someclass");

Next Article >> $(“#ID”) is fast enough

Custom Events in jQuery

JC Fant IV — Thu, 07 May 2009 23:33:44 +0000

*quick note: I originally posted this on trulyevil.com. However its time to move sites and actually keep something up and running for a while.

Events seem daunting at first, but really jQuery makes them super simple. Events can be used to alter behavior or even have multiple events happen on a single state change.

We all know about events like click, onkeydown, onmousedown, onmouseover, etc. But you can fire custom events as well. First you need to understand how to fire events. You can do this by using the $().trigger() event through jQuery.

To do this, we will attach an event for the onchange to a select input. Then when the value changes we will fire a custom event called “update”.

First, the select box.


$(’select.test’).change( function() { 
     $(’select.test’).trigger(‘update’, $(this).val()); 
});

Now we need to listen to this event, we can do this by using .bind() to listen to events triggered on a DOM element.


$(’select.test’).bind(‘update’, function(e, data) { 
     console.log(data);
});

Thats the basic way of firing and listening to custom events in jQuery. We can attach more listeners to the “update” event by attaching them in the same way.

We can also do this in a more OO way. Lets say we have multiple objects/plugins on the page that need to update when the custom event is fired. We can do this by adding the bind code into the object, then when the event is fired we can update our objects.


 var object1 = new function() {
     var obj = this;
     this.name = “Object 1″;

     $(’select.test’).bind(‘update’, function(e, data) { obj.update(data); });

     this.update = function(data){
         console.log(“Update from %o with %o”, this, data);
     };

     return this;
 };

 var object2 = new function() {
     var obj = this;
     this.name = “Object 2″;

     $(’select.test’).bind(‘update’, function(e, data) { obj.update(data); });

     this.update = function(data){
         console.log(“Update from %o with %o”, this, data);
     };

     return this;
};

The console will log the following:
Update from Object name=Object 1 with ” Test 1″
Update from Object name=Object 2 with ” Test 1″

Currently we have just been passing the value to our update event, BUT you can actually pass more than just the value. You can pass ANY of javascript built in data types, including functions, objects and arrays. If we update the trigger to pass the jQuery object, here is what it would look like:


$(’select.test’).change( function() { $(’select.test’).trigger(‘update’, $(this)); } );

And now our console would log something like the following:
Update from Object name=Object 1 with