Last Night, noConflict Saved the Project

or

“jQuery’s noConflict in Action”

As Interactive Developers, we all have our preferred javascript frameworks to aid our quest in building rich, interactive sites.  Some popular (and cost-free) frameworks out now include Prototype, MooTools, and YUI, but emerging as a leader in this space is jQuery, the “write less, do more” framework (as it’s been dubbed…)  These frameworks allow us to focus on the actual quality of interaction rather than spending time (and our clients’ money) writing widgets like sliders, accordions and drag-and-drop from scratch.  A common best practice is to use only one framework per page, but what happens when you absolutely, positively *must* use two frameworks on the same page?  What happens when the libraries you choose have numerous conflicts in their namespaces?   Molecular interface developers were recently tasked with overcoming this obstacle for a client and we found that jQuery had the easiest and most complete implementation of conflict evasion between javascript libraries.   I explain after the break:

Recently, Molecular was tasked with creating an interactive wrapper (header, menus, footer) for a global company which hosted hundreds of companion microsites around which this new wrapper framework would live.  The catch — these microsites were created by agencies around the world who were free to use whatever javascript libraries they chose. To save time and budget on the project, we already knew that we would need to utilize a library, the question was ‘which one?’  Conventional wisdom was that with hundreds of agency-developed microsites out there, two or more would certainly be using a library different than whatever library we chose.  Additionally, we didn’t want any of the agencies to be forced to change any javascript code that had previously been verified bug-free by numerous QA processes. One danger to these objectives was that some libraries such as Prototype, mooTools and jQuery all use a selector shortcut called ‘$‘.  If we chose one of these libraries, how would we be able to avoid such namespace collisions?   What would happen if one of these microsites was using a previous version of the *same* library?

Thankfully, jQuery’s core framework contains the ability to avoid any namespace collisions with other libraries via its noConflict method.   This would turn out to be another reason we chose jQuery as the framework for this navigation wrapper.  Not only could we seamlessly integrate with sites leveraging other libraries, we could also allow agencies to keep using earlier versions of jQuery without modifying their code at all.  Below are examples in how we tackled each scenario:

Scenario 1: Integrating with a conflicting library (not a different version of jQuery)

Here, we call the basic ‘noConflict’ method which removes jQuery’s ‘$’ alias from scope and leaves any selection work to the original “jQuery” function. At this point, any conflicting methods (like ‘$’) are relegated to the non-jQuery library. Note: Here, it doesn’t matter in what order the libraries are introduced into the page.

Step 1: Call jQuery (Note: script tags don’t contain “type” or “language” attributes for space reasons…)

<script ... src="js/jquery-1.2.6.js" ></script>

Step 2: Call your non-jQuery library (Note: script tags don’t contain “type” or “language” attributes for space reasons…

<script ... src="js/otherlibrary.js" ></script>

Step 3: set jQuery to noConflict mode.

jQuery.noConflict();

Step 4: Now, any time you utilize a conflicting method, it will be call via the non-jQuery library. Now to call a jQuery method, use the jQuery namespace.

$(selector).dosomething(); //not jQuery
jQuery(selector).dosomething(); //this is jQuery

Step 4a: You also have the option to encapsulate functions using the “$” command in self-executing functions like the one below:

(function($) {
$(function() {
$(selector).dosomething(); //this is jQuery
});
})(jQuery)

$(selector).dosomething(); //this is the other library

Scenario 2: Integrating with a different version of jQuery

In this instance, we call the ‘extreme’ version of noConflict which requires the developer to create an alias for their version of jQuery and assign it the value of noConflict. This scenario would resolve BOTH challenges. An important point here is that if you are attempting to use any jQuery plugins with a version of jQuery set to “noConflict” mode, any plugins you intend to use should be updated as well (you’ll need to change any references to “jQuery” or “$” to the alias you create.)    Note: Here, it *does* matter in what order the libraries are introduced into the page. YOUR jQuery must must be declaired and aliased before making a reference to the other library.

Step 1: Call jQuery (Note: script tags don’t contain “type” or “language” attributes for space reasons…)

<script ... src="js/jquery-1.2.6.js" ></script>


Step 2: Create a new object and assign it the noConflict method (with a parameter of the boolean “true”)

var $jQ= {};
$jQ = jQuery.noConflict(true);


Step 3: Call your other library. Again, this must come *after* the jQuery.js has been referenced and set to noConflict mode.
<script ... src="js/jquery-1.2.1.js" ></script>


Step 4: At this point, to call a jQuery method, you will use your new alias. To call your other library (or different version of jQuery), continue to use “$” or “jQuery”

$jQ(selector).dosomething(); //your "noConflict" jQuery method
$(selector).dosomething();//your other library's method


Following these easy steps will allow you to overcome any library namespace collisions. For more information on this topic, check out the jQuery documentation on noConflict() or this tutorial.