views:

30

answers:

3

There's something about the "standard" jQuery plugin definition that I can't seem to understand, and it seems that no plugin tutorial out there explains it.
Most plugin definitions I've seen are something like:

(function($) {
    $.extend($.fn, {
        pluginName: function( options )
            ...
    });
})(jQuery);

Now, while I understand what the function($) { ... } part does (makes sure that jquery works with $ even in noConflict mode, creates a "private" method etc), I don't get why the very first character is (, and it ends with )(jQuery).

Is it needed to make plugins chainable? Can it be safely ignored?

Edit

Variation of the same definition:

;(function($) { // why is ; there?
A: 

the construct (..)(jQuery) is the closure used to "insert" inside the namespace "jquery"

dafi
+2  A: 

It simply defines an anonymous function and calls it right away, you can think of it like this:

var f = function($) { /* Code goes here, can use $ */ };
f(jQuery); // assings jQuery to $ parameter

Now if you combine those two statements into one, you get:

(function($) { /* Code goes here */ })(jQuery);

That's all it really does. Doing it with an anonymous function this way won't pollute the global scope with useless variable names, and lets you use the $ symbol even in noConflict mode.

reko_t
that makes sense now, thank you!
Razor
+1  A: 

Hey Mate.

The wrapping lines are to do with creating an anonymous function and then calling it. jQuery is passed and then aliased to $ such that your plugin will still work in jQuery noConflict mode ($ will not be defined). The anonymous function is so our plugin get's a local scope so we don't accidentally define any global variables as they are bad.

Another point as a jQuery Plugin developer myself, I wouldn't really suggest developing plugins using that code: $.extend($.fn, { pluginName: function( options ) ... });

All this will do is just add a series of functions to the jQuery Object Prototype, so for instance you can call $('#el').pluginName(). This is fine if your plugin is extremely simple, but it can become quite difficult to maintain as your plugin is still defined in a procedural fashion rather than object oriented.

A better approach would be something like this:

$.pluginName = {
    init: function(){
        var myPlugin = $.pluginName;

        // Attach jQuery Object Prototype (fn function)
        $.fn.pluginName = myPlugin.fn;

        // Attach DomReady
        $(function(){
            myPlugin.domReady();
        });
    }
    domReady: function(){},
    fn: function(){
        // your jQuery object function
    }
});

// Initialise our Plugin
$.pluginName.init();

This approach also allows people to easily extend your plugin if it falls short in some area or fix code themselves without touching yours. For instance I could overwrite your fn function by doing this: $.pluginName.fn = fixedFnFunction();

This is great for community development. I also like it as it keeps what is in the jQuery Object Prototype to a minimum so less overhead.

I'm looking for the articles I used for reference about this and will post them when ready.

balupton
very useful info, although it wasn't exactly what I was asking here, +1
Razor