jQuery plugin template - best practice, convention, performance and memory impact

Question

I\'ve started to write few jQuery plugins and figured it\'d be nice to setup my IDE with a jQuery plugin template.

I have been reading some articles and posts on th

Answer 1

I've been googling and landed here so, I have to post some ideas: first I agree with @Raynos.

The most code out there that tries to build a jQuery plugin actually...is not a plugin! It's just an object stored in memory which is refered by the data property of a node/element. That's because jQuery should be seen and used as a tool side by side with a class library (to remedy js inconsistencies from OO architecture) to build better code and yes this is not bad at all!

If you don't like classical OO behaviour stick to a prototypal library like clone.

So what our options really?

• use JQueryUI/Widget or a similar library that hides technicalities and provides abstraction
• don't use them because of complexities, learning curve and god knows future changes
• don't use them becuase you want to insist on modular design, build small-increase later
• don't use them because you might want porting/connecting your code with different libraries.

Suppose the issues addressed by the following scenario (see the complexities from this question: Which jQuery plugin design pattern should I use?):

we have nodes A, B and C that store an object reference into their data property

some of them store info in public and private accessible internal objects, some classes of these objects are connected with inheritance, all of these nodes also need some private and public singletons to work best.

What would we do? See the drawning:

classes : |  A        B         C
------------------case 1----------
members   |  |        |         |
  of      |  v        v         v
an object | var a=new A, b=new B,  c=new C
  at      |     B extends A
node X :  |  a, b, c : private
------------------case 2---------
members   |  |        |         |
  of      |  v        v         v
an object | var aa=new A, bb=new B, cc=new C
  at      |     BB extends AA
node Y :  |  aa, bb, cc : public
-------------------case 3--------
members   |  |        |         |
  of      |  v        v         v
an object | var d= D.getInstance() (private),
  at      |     e= E.getInstance() (public)
node Z :  |     D, E : Singletons

as you can see every node refers to an object - a jQuery approach - but these objects change wildely; they contain object-properties with different data stored in or, even singletons that should be...single in memory like the prototype functions of the objects. We don't want every object's function belonging to class A to be repeatedly duplicated in memory in every node's object!

Before my answer see a common approach I've seen in jQuery plugins - some of them very popular but I don't say names:

(function($, window, document, undefined){
   var x = '...', y = '...', z = '...',
       container, $container, options;
   var myPlugin = (function(){ //<----the game is lost!
      var defaults = {

      };
      function init(elem, options) {
         container = elem;
         $container = $(elem);
         options = $.extend({}, defaults, options);
      }
      return {
         pluginName: 'superPlugin',
         init: function(elem, options) {
            init(elem, options);
         }
      };
   })();
   //extend jquery
   $.fn.superPlugin = function(options) {
      return this.each(function() {
         var obj = Object.create(myPlugin); //<---lose, lose, lose!
         obj.init(this, options);
         $(this).data(obj.pluginName, obj);
      });
   };

}(jQuery, window, document));

I was watching some slides at: http://www.slideshare.net/benalman/jquery-plugin-creation from Ben Alman where he refers at slide 13 to object literals as singletons and that just knock me over: this is what the above plugin does, it creates one singleton with no chance whatsover to alter it's internal state!!!

Furthermore, at the jQuery part it stores a common reference to every single node!

My solution uses a factory to keep internal state and return an object plus it can be expanded with a class library and split in different files:

;(function($, window, document, undefined){
   var myPluginFactory = function(elem, options){
   ........
   var modelState = {
      options: null //collects data from user + default
   };
   ........
   function modeler(elem){
      modelState.options.a = new $$.A(elem.href);
      modelState.options.b = $$.B.getInstance();
   };
   ........
   return {
         pluginName: 'myPlugin',
         init: function(elem, options) {
            init(elem, options);
         },
         get_a: function(){return modelState.options.a.href;},
         get_b: function(){return modelState.options.b.toString();}
      };
   };
   //extend jquery
   $.fn.myPlugin = function(options) {
      return this.each(function() {
         var plugin = myPluginFactory(this, options);
         $(this).data(plugin.pluginName, plugin);
      });
   };
}(jQuery, window, document));

My project: https://github.com/centurianii/jsplugin

See: http://jsfiddle.net/centurianii/s4J2H/1/