I want to introduce/reinforce a pattern for developing large applications with jQuery. I did not invent any of this, but I find that the resources that describe this technique are few and far-between.– so I’m taking a shot at it.
By and large, when using jQuery, developers seem to forget the paradigms they learned for well structured code in other languages. This is likely due to the fact that jQuery is effectively neutral when it comes to your structural methodology or inheritance patterns, and therefore doesn’t push someone in any one direction. Many times in other libraries (See Dojo Declare/Provide/Require, or MooTools Class, etc.), a paradigm is used and exclusively offered, and then code generally ends up more uniform than the oh-so-common-massive-jquery-indented-chains that I’m sure you’ve seen .
I’ll jump straight to a code example of this technique in use, and then describe it’s setup and structure:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
And the html now looks more like this:
1 2 3 4
The key here is that we didn’t have to call something like $elem.append(‘Alex’) nor did we even have to consider what would happen when a speaker object was called with the speak() function. I consider this to be the key to modular development. This level of abstraction helps keep the how and the what separated (or “loosely coupled” – if you like buzzwords). The other thing that was important to note is that after we instantiate the plugin, we have a clear two-way path between our Object and our Dom Element – both have an easy way to immediately access the other. This is important, because we often have different points of entry to jump-start a routine, so being able to access the part that you need quickly and easily is important.
Implementing this technique is pretty simple, and should actually take less brain power to set up than traversing through the dom in your head to figure out a crazy chain.
Let’s start with the Speaker object.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
I use an object literal here which puts me in the Prototypal Inheritance camp, I believe, but this is just an easily digestible pattern.
As you can see, there are easy-to-read, small functions, that have a clear purpose. In our use of this pattern, we call api type methods like speak() but not necessarily an internal method (like _build). You can hide your internal functions either by naming convention (not really hiding them), or by using something like the module pattern. In our simple example, I have just added an underscore to the beginning of the function to indicate that it’s private.
Code that is organized like this is much easier to test and to change/read. This also allows you to change the way things function without changing the way that the Object api is used. For instance, we could change the speak method to alert the string instead of append it to the related element. We would have to change the internals of the speak function, but we could keep our call to it the same.
The bridge that we build is probably the most interesting part of this pattern. It’s a different approach than many of the popular plugins take (slightly different than jquery ui), but it has a few really great benefits.
The most simple way to do this is by hand:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
And that’s it!
Now you have separated the creation of the plugin from the actual code itself. You are using the plugin to attach objects (with any inheritance patten) to dom elements and visa versa, but the plugin itself is just the connection and initialization code. This means that we could generalize this process further. I first saw this from Scott Gonzalez (of the jQuery UI team) and his code later became the ‘widget factory’ in jQuery UI. I prefer to not pass strings into my plugins in order to call functions, but it’s a valid approach as some people would take issue with having to pull out the object each time they started with a dom element.
Here is some code that might get you started writing/using a ‘bridge’ function (bridge is what’s found now in jQuery UI 1.8) that can help you attach your general code with a given plugin (since writing that same initialization plugin code multiple times would get old and defeat the whole DRY principle that our inheritance model has hopefully provided). This code is mostly courtesy of Scott Gonzalez because I couldn’t think of a more stripped down elegant approach to this. I changed it to accept Objects instead of Constructor Functions because that works a little better with my example (prototypal inheritance). I also force it to call my init function in order to save myself an extra call. (This example shows Scott’s use of this method along with John Resig’s Simple-Inheritance implementation – also very cool.)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
That’s about all there is to it. I’d encourage you to pick some pattern for your development that isn’t just inline chaining of jQuery function calls. This way of breaking up and organizing functionality in your code serves as a quick and easy jumping-off point for testing and modularity. It’s much easier to test the individual functions of a modular object than it is to write tests for a single-line chain of jQuery calls.
Also, I do get some feedback along the lines of “well, my code is not a plugin” – “this isn’t applicable to my code” – but I usually tend to disagree. The stigma that a jQuery plugin has to be for general consumption is flawed. I encourage you to use the plugin architecture if you are creating functionality based on a dom element selection. For instance, if you are adding an error notification system, it would be very easy to create a notification object that attaches to a div and has the methods required for notification directly attached to it, rather than having a function that merely hides and shows random dom elements.
I am doing a round up of performance on a lot of this inheritance usage and I should get to writing another entry on that soon, but from my early tests, using reasonable inheritance is generally not that expensive. If you are pushing the limits of CPUs and browser rendering, you might have to make some sacrifices, but for the general case, the instantiation hit of inherited objects is probably well worth your while.
I’d love to hear about the way you approach this problem.