Question

So there is this great jQuery library and you can get amazing stuff done using it. Write less, do more – indeed.

But every shop may feel they have some recurring usage patterns (same widgets, same dialogues, same whatnot), and as they always use jQuery they think it convenient to extend jQuery a little bit to incorporate their custom in-house stuff.

Now let me expand a bit on the meaning of that little word “extend”, which I’m going to do by describing the situation at my current workplace. The JavaScript guys at that shop have made a copy of the jQuery library at version X (rather recent) and added some stuff of their own. In fact, the in-house stuff is based on jQuery SDK, which as far as I can tell isn’t known to many people, as it doesn’t seem to be known to Google as of April 6, 2011. You can see that it has a jQuery.ready function, which as fas as I can tell is not part of the stock jQuery library. So okay, they extended jQuery.

That jQuery.ready function is a good place to start talking about the potential (and manifest) drawbacks of the approach that has been taken. Well, you’d think ready means ready, but alas, that isn’t so: instead of registering a callback for when the DOM is ready enough, it appears to execute as soon as the <script> is parsed. Which is really counter-intuitive; they should have called the function jQuery.notReady, that would have been fair.

Fair, because I’m a user of that modified library. And that flaw isn’t the only one, I also found that the ep.ajax function, which is supposed to behave like jQuery.ajax, but with some extensions, doesn’t execute the success callback. [Update for correctness’ sake: This failure to execute the callback was due to callback code accessing an inexistant property.] Plus, simple dialogues as invoked by the dialog function of the modified version of the library look broken and don’t work properly.

(I really, really think you should never take away a well-known, excellent and reliable API from the user just for being able to add some custom stuff – much less, you should alter that API, even when you’re not intent on breaking it.)

Which brings me to the topic of my question, probably easily answerable. Are these flaws, if not necessary, so at least common backlashes one will encounter when extending jQuery? I’m asking because I’m not a JavaScript or jQuery expert by far, but I know from using other programming languages that it’s perfectly possible to extend object systems in a clean way without altering the original library version. In fact, you’d never do that, because then you’re on your own with QA, bugfixes, updates, documentation, etc. So what’s the deal? Is this impossible in JavaScript? Or did they just sort of botch the job of extending jQuery? How would you go about extending jQuery and jQuery UI in a clean way? Pointers welcome. Thank you.

Answer 1

It is really, really easy to extend jQuery!

That is why plugins for jQuery are so plentiful.

Take a look at this page: http://docs.jquery.com/Plugins/Authoring

To summarize, all you need to do is this:

$.fn.myPlugin = function() { 
    // 'this' refers to the jQuery collection

    return this.each(function() {
      // now 'this' refers to each element in
      // the jQuery collection
    });
};

The worst thing you could do is name your plugin (extension of jQuery) the same name as an existing jQuery method, e.g. css. In fact, you want to leave jQuery untouched, and simply add any plugins after that to provide you with the additional functionality/widgets you need.