JAVA SCRIPT - Safely Combining Several Libraries in Your Applications

 Safely Combining Several Libraries in Your Applications

Problem

You want to incorporate more than one external library, as well as your own, into one application without each stepping all over the others.

Solution

The safest approach for using multiple libraries is to pick ones that are all based on the same framework, such as using only libraries based on jQuery, the framework used in earlier recipes. 

If that strategy doesn’t work, make sure the libraries all use good programming practices, and none are overriding functionality or event handling provided by the others.

EXPLAIN

Regardless of library purpose, there are fundamental rules governing the behavior of libraries that must be followed. Well-designed libraries do not do things like this:

window.onload=function() {...}

I use the DOM Level 0 window.onload event handler with some of the examples in the book because it’s quick, simple, and doesn’t add a lot of code to the sample.

However, if you have one library that uses the old DOM Level 0 event handling, it overwrites the event capturing utilized by the other libraries and your own application.

Well-designed libraries don’t use DOM Level 0 event handling. Well-designed libraries also namespace all of their functionality. You won’t find the following in a well-defined library:

function foo() { ... }
function bar() { ... }

Each function like this ends up in the global space, which increases the likelihood of clashes with other libraries, and your own applications. Well-designed libraries typically use an anonymous function, ensuring no clash with whatever is exposed to the global space:

 var root = this;
 ...
 if (typeof define === 'function' && define.amd) {
 define('underscore', [], function() {
 return _;
 });
 }
}).call(this);

A library that plays well with other libraries and applications will not extend existing objects via the prototype object. Yes, I know it’s a wonderful way of extending objects, and fundamental to JavaScript, but you can’t control one library from overriding another if both are extending the prototype property for the same object.

Besides, if the frame‐ work and external libraries you use don’t extend existing objects via the prototype, this leaves you free to play in your application. Come to that, library builders should never assume that their library is the only one used in a project.

Well-designed libraries provide event hooks so that you can hook into the library at the points where it performs a major action. the jQuery plug-in described in the solution provided event handler hooks you can use to provide your own func‐ tionality before or after the plug-in’s validation routine.

Well-designed libraries provide good documentation of all of the publicly exposed bits, including methods, properties, and events. You shouldn’t have to guess how to use the library, or examine minute portions of the code, in order to figure out what you need to do.

Well-designed libraries are thoroughly tested, and provide a way to report bugs and view existing bugs. Test code should be accessible wherever it’s hosted. If there’s a major security problem with an existing library, you need to know about it. If there are minor bugs, you need to know about these, too.


Well-designed libraries provide nonminified, original source code. This isn’t essential —just helpful, and something I look for in a library. It goes without saying that a good library is one actively maintained, but it can’t hurt to repeat this assertion.

An even better library is one that’s open sourced, and maintained by a community of users, who hopefully play well together—or is one you can maintain on your own, if the original maintainer can no longer do so. To summarize:

• A good library does not use DOM Level 0 event handling.
• A well-defined library uses an anonymous function to wrap its functionality and doesn’t pollute the global namespace.
• A well-defined library introduces few global objects.
• Libraries that play well with others provide event hooks. Well-behaved libraries also don’t extend existing objects via the prototype property.
• Solid libraries are well-tested, and provide these tests as deliverables.
• Stable libraries are actively maintained, and preferably, open sourced.
• Secure libraries provide documentation of known bugs and problems, and a way to report on any bugs and problems you find.
• Usable libraries are well-documented. Bandwidth-friendly libraries are optimized and compressed, though you can always compress the library yourself.
• Confident libraries aren’t built on the assumption that no other library will be used.

For the most part, you should be able to find what you need and have it work with your preferred framework. Be cautious if a library requires you to add a new framework, that needs to coexist with another framework. However, most well-built framework libraries could work with others.

As an example of framework coexistence, if you use jQuery, you can use another frame‐ work library, such as Underscore or Mootools. The use of global namespaces should prevent name clashes. The only exception to the namespace rule is the dollar sign ($) function, which can be used in other libraries.

You can override the $ by adding the following, after all the libraries have been loaded:

var $j = jQuery.noConflict();

Once you add this code, instead of:

$("#elem").fadeOut('slow');

use :

$j("#elem").fadeOut('slow');

You can use most well-made framework libraries together, but there is tremendous overlap in functionality between the libraries, and this overlap in functionality comes with a cost: bandwidth to download the libraries.

Try to avoid using more than one framework library at a time. Find the one you like, and be prepared to commit to it for some time to come.