jQuery plugin design recommendations

Reference: Learning jQuery (Fourth Edition), Chapter 8

Protect the dollar ($) alias from potential interference from other libraries by using jQuery insstead or passing $ into an immediately invoked frunction expression (IIFE), so that it can be used as a local variable.

Whether extending the jQuery object with $.myPlugin or the jQuery prototype with $.fn.myPlugin, add no more than one property to the $ namespace. Additional public methods and properties should be added to the plugin’s namespace (for example, $.myPlugin.publicMethod or $.fn.myPlugin.pluginProperty).

Provide and object containing default options for the plugin: $.fn.myPlugin.defaults = {size: ‘large’}.

Allow the plugin user to optionally override any of the default settings for all subsequent calls to the method ($.fn.myPlugin.defaults.size = ‘medium’;) or for a single call ($(‘div’).myPlugin({size: ‘small’});).

In most cases when extending the jQuery prototype $.fn.myPlugin, return this to allow allow the plugin user to chain additional jQuery methods to it (for example, $(‘div’).myPlugin().find(‘p’).addClass(‘foo’)).

When extending the jQuery prototype ($.fn.myPlugin), enforce implicit iteration by calling this.each().

Employ callback functions when appropriate to allow for flexible modification of the plugin’s behavior without having to change the plugin’s code.

If the plugin calls for user interface elements or needs to track elements’ state, create it with the jQuery UI widget factory.

Maintain a set of automated unit tests for the plugin with a testing framework such as QUnit to ensure that it works as expected.

Use a version control system such as Git to track revisions to the code. Consider hosting the plugin publicly on GitHub (http://github.com/) and allowing others to contribute.

If making the plugin available for others to use, make the licensing ters clear. Consider using the MIT license, which jQuery also uses.