using javascript plugins in larger systems

Most web developers do not code all the JavaScript they use themselves. Framewoks like Dojo, jQuery and Prototype are a nice example of that. As a developer it is also interesting in many situations to use plugins to make things like image rotators and cover flows. No sense in doing all that work yourself.

There are actually a couple of things you need to look out for when using plugins. It is not as trivial as: “plug it in & turn me on“.

Picking the right one

Have you ever had the problem of having too many options? Well, if you want a image rotator widget for your site there are about 101 different plugin’s to choose from. How do you pick one?

Who fit’s the shoe?

As there are many to choose from… look at what you need and see if any match your needs. Also look at other that come close but are more customizable.

Maintenance

We tend to forget that we are still using code. code can have bugs that need to be fixed, are you going to do it or do you want or need the help of the original creator? Be on the lookout if the developer that created the plugin is still updating it if needed. Well maintained plugins are so much better then one that had it’s last update years ago.

License

We tend to forget this one. A plugin might be free of charge… but not free to do with what you want. Make sure you understand the different licensing models. Check if the license used for the desired plugin is compatible with your situation. We don’t want to have a lawsuit just because we didn’t check.

Loose coupling

I see this way to often in applications that use a lot of different plugins. All plugins are coupled into the application. If one fails it will need to be replaced all over the system. I always advise to create a loose coupling layer for plugins.

How does that work?

well basically you create a proxy for the actual plugin call. If a jQuery plugin is called like this:

$("#my_selector").addCustomPlugin();

Then you create your own plugin that does something like this:

(function ($) {
    $.fn.mySpecialProxyToCustomPlugin = function() {
        $(this.selector).addCustomPlugin();
    };
})(jQuery);

Of course you can pass parameters if needed by just passing the parameters from one to the other.

Why do I want to do this?

Loose coupling is all about detaching components so they keep as interchangeable as possible. Following this idea should allow you to easily switch to another plugin without having to change every call to the plugin in your application. So if you need to switch plugins it should be a lot easier.

Another thing is that you do not want to do the same configuration over and over gain. I talked about passing parameters. You can also standard parameters for your application to the proxy. This way you don’t have to set it every time you call the plugin. jQuery plugins tend to use a lot of options hashes. What you can do is:

(function ($) {
    $.fn.mySpecialProxyToCustomPlugin = function(options) {
        var options = $.extend({
            myCustomOption: 'foobar',
            theAnswer: 42,
            winning: true
        }, options);

        $(this.selector).addCustomPlugin(options);
    };
})(jQuery);

Now you are passing the options along as the original plugin and you just add some standard values that apply to your situation.

The last but not least thing is that you can also extend the plugin with your proxy (that does not make it a proxy anymore but that is besides the point). What I this allows you to do is keep your alterations separate from the original plugin. This way you can keep updating the plugin to new versions without breaking your code and keeping compatibility with your usage.

So, happy coding!

Advertisements

, ,

  1. #1 by Krishna upadhyay on 2011/07/10 - 14:47

    because javascript is complex like java & c.

  2. #2 by Joost Elfering on 2011/07/10 - 14:53

    complex is not the right reason for the example I’m making here. I think even smaller very simple plugins should also be used in this way when you are creating a larger system. The main idea behind it is that you want to do separation of concerns.

    It is one of the reasons why ActiveRecord is so popular within the Ruby community. ActiveRecord separates SQL syntax and data setting and retrieval statements. This allows you to just switch to another SQL database without having to deal with all the small syntax differences in the SQL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: