jQuery design pattern for selectors to improve code maintainability?

Question

Yesterday I had to go back to a page I had worked on a few weeks ago to redo the UI. The UI consisted of a jQuery UI tab control with 3 tabs. Each tab had 3-5 controls inside of it, and a submit button to only submit the data within the tab. I had to reorganize some of the tabs, remove some textboxes, add some drop down lists, modify some behaviors and even work a bit on the client side validation (which uses jQuery Validation). What I found during this excercise, thought, was that I had to go back and recheck each and every one of my jQuery selectors. Some were left intact, but many of them changed.

I'm wondering what design pattern (if any) do people use to avoid or minimize the effect of refactoring or reworking a webpage that had heavy jQuery usage. I'm sure it can't be just "Search" + "Search And Replace".

jAndy · Accepted Answer · 2011-07-06T13:03:28.677

It's in general a very good idea to store node references commonly used. This could be done in some kind of "init script file" or in each "module" if you have modules separated by files.

For instance

var myNamespace = window.myNamespace || { };

$(document).ready(function() {
    myNamespace.nodes = {
        header:   $('#header'),
        content:  $('#overlay > .content'),
        footer:   $('#footer')
    };
});

somewhere else in your code you should only access elements over such a hash lookup. Later if selectors change, you only need to replace / modify the selector strings in one place and all the rest keeps working.

// somefile.js
var myNamespace = window.myNamespace || { },
    myNodes = myNamespace.nodes;

$(document).ready(function() {
    if( myNodes ) {
        myNodes.content.animate({ top: '+=200px' }, 1000);
    }
    else {
        throw new Error('Arrrrrrr the <center> cannot hold! it is too late');
    }
});

That concept also provides a better performance for your whole webapp. By quering nodes only once, since this is still a pretty expensive DOM operation.

I was thinking about doing this, but wasn't sure if it was a good practice or not. I think this answer validates it. Something about having all of those selectors around in my code makes me uncomfortable. Maybe it's a side effect of working with static languages most of the time. — enriquein, Jul 06 '11 at 13:14

Saeed Neamati · Answer 2 · 2011-07-06T13:10:22.257

I think of this list:

Having no track of HTML elements in your selectors, because if you show your message in a paragraph today, maybe you want to show it in an span tomorrow.
Use semantic Id and classes. (semantic naming and IDs prevents from future changes to those names, thus less selector changes)
Use multiple classes, not just one long descriptive class. (something like tagging. Instead of having error-message class, have error message classes)
Use less traversing, that is, going from child to parent and from this node to previous, or siblings and stuff. (it's directly related to nesting levels).

score 1 · Answer 3 · answered Jul 06 '11 at 12:55

Well, one good practice that i use is never use next() and prev() but always a combination o closest() and find(). This way, if you move things around, you don't have to change your jquery code (most of the times).

Another thing is to cache the selector in a variable if you use it more than once:

 var  myDiv = $('myDiv');

this improves performance and if you cange the id you don't have to search and replace. Other than that i can't help.

jQuery design pattern for selectors to improve code maintainability?

3 Answers3