Crawl, Walk, Run

Any JavaScript developer who spends more than a blink of an eye working with the DOM has probably come despise the API. It’s not that there’s a dearth of features (welll….); I think it’s the verbosity that causes modern application development woes. For the one-off script that adds an onclick or modifies some text the DOM API is fine and dandy. Try scaling up to developing an application or, perhaps, a framework and things get annoying and messy right quick.

When Tommy finally gave jQuery a try and discovered there was no native DOM manipulation tools he decided to roll his own plug-in he calls FluentDom. The code is clean and quality, as I’d expect from him, but the interface drives me bonkers.

I’m a fan of configuration over convention, a concept which, when combined with my MooTools history, has lead me to favor using object literals as configuration “objects”. When I use MooTools to create a new element the only arguments are the element type and an object literal with any configuration options. This is where Tommy’s code style differs. In FluentDom you set a specific attribute with specific methods with calls able to be chained together. This isn’t to say that FluentDom couldn’t be used with a configuration object, it’s just not as clean an implementation as I prefer.

In a message to him I said this:

The benefit to setting attributes via an object literal is that I can use one set of preset attribute values and pass that around. Quite handy if you’re doing something like iterating and creating a list of similar elements but particular ones might have subtle differences. Also easier to maintain and extend. Given your code it’d be a trivial modification to do this during a create call.

Which do readers prefer, specific, chainable method calls or ambiguous configuration object?

Despite research that feels all-inclusive, reading other blogger’s posts and the collective groans on Marc’s message board (not to mention my own now-invalid feeling of accomplishment) I am still being bested by the infamous “child pid xxxxx exit signal Segmentation fault (11)” issue.

From what I can tell the segmentation fault occurs when I execute odbc_fetch_array. I cannot tell you what a joy it is to try and debug a script that dies when using a built-in function. PHP 5.3 how I wanted to love you. How I so very much despise you now.

If anybody out there in the tubes has any helpful, constructive ideas I sure would appreciate some feedback in the comments.

A coworker, Tommy, posed an interesting question to me the other day. How would one handle dynamically adding elements to a form, especially with regard to giving the user ability to remove those elements? We both admitted to implementing this a few times and he described to me his method of iterating through elements until the right node was found and then removing it.

As a habit I avoid DOM traversals whenever possible so I suggested an alternate solution. Instead of having a controller function look for some kind of unique ID or scan the DOM why not break down the control to the individual element and programmatically make the removing function a closure with a reference to each node. That way the code to remove an element is only ever concerned with its own instance. No crawling the DOM, no messy lookups, no muss no fuss.

If that didn’t make sense, perhaps this snippet will.

var addControls = function(element)
{
	var remove = document.createElement('input');
	remove.setAttribute('type', 'button');
	remove.setAttribute('value', '-');
	remove.onclick = function()
	{
		return function(self)
		{
			if(confirm('Are you sure?'))
				self.parentNode.removeChild(self);
		}(element);
	}
	
	element.appendChild(remove);
}

addControls(someNodeThatYouAlreadyFound);

Pretty simple. Questions? Let em rip in the comments.

If you don’t already know, polluting the global variable pool is a bad, evil thing in JavaScript land. If you’re not concerned with overwriting existing code then at least think about protecting your code from being overwritten by keeping it in your own namespace. All you need to create a namespace in JavaScript is an object literal.

Say you’re tasked with incorporating a third-party widget into your home page. You drop in their include but suddenly one of the scripts on your site breaks. You haven’t changed your code so you assume it’s the include causing trouble. However, a JSLint shows that their syntax checks out fine. Looking through your functions you narrow the misbehaving lines down to the following:

function findElement(el) {
    return document.getElementById(el);
}

function updateNews(content) {
    findElement('news').innerHTML=content;
}

That is some horrible code. Worse, that’s horrible code in the global pool. Cracking open the third-party include you see this:

updateNews = function(container,source,freq)
{
    // Snip....
}

My, that function name looks awfully familiar. In fact, it’s the same as yours. That means your code and the third-party code are fighting in the global variable pool. What’s a clever programmer to do? Do what works in other languages, of course!

Time to carve out your own namespace

This is ridiculously easy if you understand what object literals are and how to self-invoke an anonymous function. Those terms both sound scarier than they are. You simply create an object literal to act as your namespace &#8211 which is a bucket for all your code – then use anonymous functions to assign functions into it. Keeping with the theme of being a polite player in the global pool also make sure your namespace is either brand new or extends any existing namespace.

var AY = AY || {}; //Don't overwrite existing namespaces
AY.News = function() //A 'News' bucket for all news-related tasks
{
    //The 'var' forces the findElement method 
    //into the News scope, not global
    var findElement = function(el)
    {
        return document.getElementById(el);
    }
    
    //Anything in the return becomes publicly accessible, yet 
    //is also able to access private methods and variables
    return {
        updateNews: function(content)
        {
            findElement('news').innerHTML = content;
        }
    }
}(); //Self-invoke to make this available immediately
AY.News.updateNews('Hai');

What’s happening here? Well instead of dropping all of your code into the global you can stash it in a single namespace. In my case I’ve named my namespace as AY, after my name. I used all capital letters to signify that this is not a variable or method belonging to any other code. For news-related items I’ve created a News bucket.

Inside of my News bucket there are a few things happening. I’ve decided that findElement should be a private method in my namespace so by prepending it with the var = I designate it as existing only inside the AY.News namespace. Without a public accessor no outside code can run that method. My return passes an object literal which houses any public methods, in this case the updateNews method. Because they are a part of my AY.News namespace these public methods can access private methods, which is why the updateNews code still works.

Finally, the closing parentheses cause the anonymous function to automatically run, or self-invoke. This action executes the function and, during its execution, hits the return which is what causes the return data to be assigned to AY.News. The return is an object literal itself that contains a reference to the “private” updateNews, which will execute the update.

That’s it! There’s no more to it. I’ll grant that for personal scripts this technique is not absolutely necessary but if you ever want your code to play nicely in another environment it’s a good practice and makes other programmers less hesitant to use your code. Comments regarding execution of this technique are more than welcome. This is my personal flavor and because of JavaScript’s flexibility I’m sure there are some other great techniques out there. Comment away!

Recommended reading:

• A JavaScript Module Pattern
• JavaScript Programming patterns
• Namespacing Your JavaScript

2009-06-17: Reordered and cleaned up copy.