JAVA SCRIPT - Packaging Your Code

Packaging Your Code 

Problem

You want to package your code for reuse in your own projects, and possible reuse by others.

Solution

If your code is in one big file, look for opportunities to extract reusable functionality into self-contained objects in a separate library. If you find you have a set of functions you repeat in all of your applications, consider packaging them for reuse via an object literal. Transform the following:

function getElem(identifier) {
 return document.getElementById(identifier);
}
function stripslashes (str) {
 return str.replace(/\\/g, '');
}
function removeAngleBrackets(str) {
 return str.replace(/

/g,'>'); } to :

var jscbObject = {
 // return element
 getElem : function (identifier) {
 return document.getElementById(identifier);
 },
 stripslashes : function(str) {
 return str.replace(/\\/g, '');
 },
 removeAngleBrackets: function(str) {
 return str.replace(/

/g,'>'); } };

EXPLAIN

We can’t find everything we need in external libraries. On rare occasions, there isn’t a library that provides the basic functionality we need, or you need to extend an existing library. In addition, our business requirements are unique and requires their own JavaScript functionality. Both types of code can be packaged up into libraries, either to make them easier to use in our applications, or to share with the world. 

There is some fundamental restructuring you need to perform on the code in order to neatly package it into a library. In the solution, I’ve taken three functions in the global space and converted them into three methods on one object. Not only does this reduce the clutter in the global space, but it helps prevent clashes with similar-sounding func‐ tion names in other libraries. 

Even as global functions, though, they’re a step up from code that’s hardcoded to a specific use. For instance, if your code has the following to access a style property from an element:

// get width
var style;
var elem = div.getElementById("elem");
if (elem.currentStyle) {
 style = elem.currentStyle["width"];
} else if (document.defaultView &&
 document.defaultView.getComputedStyle) {
 style = document.defaultView.getComputedStyle(elem,null)
 .getPropertyValue("width");
}

Repeating this code in more than one function in your application can quickly bloat the size of the JavaScript, as well as make it harder to read. Package the code by extracting it into a reusable function, and eventually into a new member of your library object literal:

var jscbObject = {
 // get stylesheet style
 getStyle : function (obj, styleName) {
 if (obj.currentStyle) {
 return obj.currentStyle[styleName];
 } else if (document.defaultView &&
 document.defaultView.getComputedStyle) {
 return
 document.defaultView.getComputedStyle(obj,null)
 .getPropertyValue(styleName);
 }
 return undefined;
 },
...
}

As you split your code into libraries of reusable objects, look for an opportunity to collect your code into layers of functionality.


Before the advent of jQuery and other very nice user interface libraries, I had one library, bb.js, that provided basic functionality such as event handling, accessing generic style elements, and processing keyboard events. I had another library, mtwimg.js, providing image handling in a web page, similar to what the library Lightbox 2 provides, but on a much smaller scale.

My image handling library is built on my general library, so that I don’t have to repeat the functionality in both libraries, but I also keep my bb.js library small, and focused When I created a third library, accordion.js, which created automatic accordion widgets (also sometimes called collapsible sections), it was also built on the bb.js generic library, considerably reducing the development time.

More importantly, if I eventually decide to drop support for my generic library in favor of another externally developed library, such as jQuery, though the internal functionality in accordion.js and mtwimg.js has to change, the web pages that use both don’t, because the latter two libraries’ outwardfacing functionality isn’t impacted. This is a concept known as refactoring: improving the efficiency of your code without affecting the external functionality.

Oh, and while you’re at it: document your code. Though you may provide a minified version of your code for production use, consider providing a nonminified, welldocumented version of your JavaScript libraries so that others can learn from your code, the same as you’re able to learn from theirs.