Posts Tagged ‘tutorial’

Building stateful jQuery plugins

May 15th, 2010


Over the past few years, jQuery has dominated the web development community with its simple, yet brilliant, API. The “find elements, do something” pattern and ability to chain function calls together combine to create code that reads like English. jQuery’s simplicity and almost nonexistent learning curve have made it extremely popular among developers and designers alike. Equally as important as its ease of use is its extensibility. With an extension system that makes creating a plugin as simple as writing a function, jQuery has been able to maintain a lean core while offering an almost unlimited amount of functionality.

The combination of jQuery’s simple plugin system and its active community has resulted in over 2,000 plugins being listed in its plugin repository. However, like all core methods, the majority of these plugins only provide stateless functionality. While many of these plugins are useful, there’s a large set of functionality that doesn’t fit into the basic plugin pattern.

A new plugin system

In order to fill this gap, jQuery UI has implemented a more advanced plugin system. The new system manages state, allows multiple functions to be exposed via a single plugin, and provides various extension points. This system is called the widget factory and is exposed as jQuery.widget. In this article, we’ll explore the various features provided by the widget factory by building a simple progress bar plugin using jQuery UI 1.8.

Building a plugin

To start, we’ll create a progress bar that just lets us set the progress once. As we can see below, this is done by calling jQuery.widget with two parameters: the name of the plugin to create and an object literal containing functions to support our plugin. When our plugin gets called, it will create a new plugin instance and all functions will be executed within the context of that instance. This is different from a standard jQuery plugin in two important ways. First, the context is an object, not a DOM element. Second, the context is always a single object, never a collection.

The name of the plugin must contain a namespace, in this case we’ve used the nmk namespace. There is currently a limitation that exactly one namespace must be used. We can also see that the widget factory has provided two properties for us. this.element is a jQuery object containing exactly one element. If our plugin is called on a jQuery object containing multiple elements, a separate plugin instance will be created for each element, and each instance will have its own this.element. The second property, this.options, is a hash containing key/value pairs for all of our plugin’s options. These options can be passed to our plugin as shown here.

When we call jQuery.widget it extends jQuery by adding a function to jQuery.fn (the system for creating a standard plugin). The name of the function it adds is based on the name you pass to jQuery.widget, without the namespace; in our case “progressbar”. The options passed to our plugin are the values that get set in this.options inside of our plugin instance. As shown below, we can specify default values for any of our options. When designing your API, you should figure out the most common use case for your plugin so that you can set appropriate default values and make all options truly optional.

Calling plugin methods

Now that we can initialize our progress bar, we’ll add the ability to perform actions by calling methods on our plugin instance. To define a plugin method, we just include the function in the object literal that we pass to jQuery.widget. We can also define “private” methods by prepending an underscore to the function name.

To call a method on a plugin instance, you pass the name of the method to the jQuery plugin. If you are calling a method that accepts parameters, you simply pass those parameters after the method name.

Note: Executing methods by passing the method name to the same jQuery function that was used to initialize the plugin may seem odd. This is done to prevent pollution of the jQuery namespace while maintaining the ability to chain method calls. Later in this article we’ll see alternative uses that may feel more natural.

Working with options

One of the methods that is automatically available to our plugin is the option method. The option method allows you to get and set options after initialization. This method works exactly like jQuery’s css and attr methods: you can pass just a name to use it as a setter, a name and value to use it as a single setter, or a hash of name/value pairs to set multiple values. When used as a getter, the plugin will return the current value of the option that corresponds to the name that was passed in. When used as a setter, the plugin’s _setOption method will be called for each option that is being set. We can specify a _setOption method in our plugin to react to option changes.

Adding callbacks

One of the easiest ways to make your plugin extensible is to add callbacks so users can react when the state of your plugin changes. We can see below how to add a callback to our progress bar to signify when the progress has reached 100%. The _trigger method takes three parameters: the name of the callback, a native event object that initiated the callback, and a hash of data relevant to the event. The callback name is the only required parameter, but the others can be very useful for users who want to implement custom functionality on top of your plugin. For example, if we were building a draggable plugin, we could pass the native mousemove event when triggering a drag callback; this would allow users to react to the drag based on the x/y coordinates provided by the event object.

Callback functions are essentially just additional options, so you can get and set them just like any other option. Whenever a callback is executed, a corresponding event is triggered as well. The event type is determined by concatenating the plugin name and the callback name. The callback and event both receive the same two parameters: an event object and a hash of data relevant to the event, as we’ll see below. Your plugin may have functionality that you want to allow the user to prevent. The best way to support this is by creating cancelable callbacks. User’s can cancel a callback, or its associated event, the same way they cancel any native event, by calling event.preventDefault() or returning false. If the user cancels the callback, the _trigger method will return false so you can implement the appropriate functionality within your plugin.

Looking under the hood

Now that we’ve seen how to build a plugin using the widget factory, let’s take a look at how it actually works. When you call jQuery.widget, it creates a constructor for your plugin and sets the object literal that you pass in as the prototype for your plugin instances. All of the functionality that automatically gets added to your plugin comes from a base widget prototype, which is defined as jQuery.Widget.prototype. When a plugin instance is created, it is stored on the original DOM element using, with the plugin name as the key.
Because the plugin instance is directly linked to the DOM element, you can access the plugin instance directly instead of going through the exposed plugin method if you want. This will allow you to call methods directly on the plugin instance instead of passing method names as strings and will also give you direct access to the plugin’s properties.

Extending a plugin’s prototype

One of the biggest benefits of having a constructor and prototype for a plugin is the ease of extending the plugin. By adding or modifying methods on the plugin’s prototype, we can modify the behavior of all instances of our plugin. For example, if we wanted to add a method to our progress bar to reset the progress to 0% we could add this method to the prototype and it would instantly be available to be called on any plugin instance.

Cleaning up

In some cases, it will make sense to allow users to apply and then later unapply your plugin. You can accomplish this via the destroy method. Within the destroy method, you should undo anything your plugin may have done during initialization or later use. The destroy method is automatically called if the element that your plugin instance is tied to is removed from the DOM, so this can be used for garbage collection as well. The default destroy method removes the link between the DOM element and the plugin instance, so it’s important to call the base function from your plugin’s destroy method.

Closing comments

The widget factory is only one way of creating stateful plugins. There are a few different models that can be used and each have their own advantages and disadvantages. The widget factory solves lots of common problems for you and can greatly improve productivity, it also greatly improves code reuse, making it a great fit for jQuery UI as well as many other stateful plugins.

You may have noticed that in this article we used the nmk namespace. The ui namespace is reserved for official jQuery UI plugins. When building your own plugins, you should create your own namespace. This makes it clear where the plugin came from and if it is part of a larger collection.

View this example in a new window

jQuery, jQuery UI , ,

Using multiple versions of jQuery

October 3rd, 2009

Whenever a new version of jQuery comes out, there are several reasons to upgrade; new features, bug fixes and performance are generally the most common. However, it’s not always possible to upgrade as soon as a new version comes out. The new version may contain an API change that would break some of your functionality or you may be using a plugin that isn’t compatible with the new version. This is where jQuery.noConflict() comes in.

History of jQuery.noConflict()

jQuery.noConflict() was added in v1.1 to support loading jQuery on a page with other code that uses the global $ variable. In this version, the only thing that jQuery.noConflict() did was revert the $ variable to what it was before jQuery was loaded. In v1.1.1, this function was modified to also return the jQuery object so that you could assign jQuery to another variable (though it was still also assigned to the global jQuery variable). v1.1.4 introduced a boolean parameter for jQuery.noConflict() to indicate whether the global jQuery variable should be reverted; this option was added to make it easy to load multiple versions of jQuery on the same page.

Using jQuery.noConflict()

Using jQuery.noConflict() to load multiple versions of jQuery is actually pretty simple. There’s essentially just one rule: load your plugins in the correct order. In order for this to work, you have to include one version of jQuery and all of the plugins for that version before including the next version and all of its plugins. You can call jQuery.noConflict() immediately before including the second version or after you have included all the plugins for the second version. Both methods will have the same final outcome, but it may be easier to keep track of what’s going on if you call jQuery.noConflict() immediately before loading the next version in the unlikely event that you need to include more than two versions of jQuery on the same page. Because this method is slightly easier to follow, we’ll use it in our example.

First we need to load both versions of jQuery:

Now we can use either version of jQuery by using the two new variables we’ve created:

This is great, but you’re probably looking at that code and thinking “I wish I could still use the $ variable.” Well, with a little help from a self-executing anonymous function, you can!

This is a pattern you’ll see in a lot of plugins (in fact it’s part of what makes this whole thing work). We’ve created a function that accepts a single parameter, $, and we call that function as soon as we define it, passing our jQuery object to it. Now we can reference our jQuery object as $ inside this function. This makes it very easy to rename your global jQuery object while keeping your existing code working with minimal modifications.

View this example in a new window

jQuery , , ,

Creating dialogs on demand

August 7th, 2009

In a previous article, I explained how to load a page into a dialog. The article focused on a simple solution to keep it easy to understand. However, that simplicity does come with a drawback; the page contents are loaded immediately after the document is ready, even if the user never opens the dialog. In this article, I’ll show how to load the page on demand while still only making a single request regardless of how many times the user opens the dialog.

On-demand page loading

In order to create the dialog on the first click, we’ll take advantage of jQuery’s .one() event binding binds a handler to an event, but the handler is only ever run once. Immediately after the handler runs it unbinds itself, preventing further execution. We’ll adapt the example from the previous article to take advantage of .one():

Adding the final touch

Now that we’ve got our dialogs loading on demand, we need to account for network latency, slow connections, etc. Previously we were loading the page contents before the user ever saw the dialog, so any delay was hidden. A simple solution for this is to just show a loading image inside the dialog until the page contents are loaded. We’ll load this image immediately on document ready to make sure that it’s ready for use when the user clicks the link to open the dialog. Loading images are generally very small in terms of file size and they can be cached by the user, so the overhead of loading the image up-front is negligible.

View this example in a new window

jQuery UI - Dialog , , , , ,

Loading a page into a dialog

April 18th, 2009

I previously showed the basic usage of the jQuery UI dialog.  In this article, I’ll show how to open a page in a dialog.  We’ve all been to sites where there’s a help link that opens a popup with some short help text.  This is usually done with a simple call attached to the click event of the link.

Making it better

The one thing that this code has going for it is that users without JavaScript will still be able to get to the page with the help content. Of course, a better implementation would move the JavaScript out of the HTML, properly separating content from behavior.  We can spruce this up by loading the content into a dialog instead of a new window:

How it works

We’re finding the link, loading the contents of the linked page into a div and creating a dialog from that div.  We then bind a click event to the link to show the dialog.  This code by itself will work in many situations.  However, the page you’re linking to may have a heading that you’re already reproducing with the dialog title.  There may also be other elements on the page that won’t make sense in a popup, such as navigational elements or a page footer.  Luckily the .load() function allows us to pass in a selector to find the contents that we care about.  In this example we’ll assume the main content of the page is in a div with an id of content.

View this example in a new window

jQuery UI - Dialog , , ,

Basic usage of the jQuery UI dialog

April 8th, 2009

The jQuery UI dialog, like many jQuery UI plugins, is extremely easy to get started with but has a few areas that causes new users some trouble.  One of the most commonly asked questions on the jquery-ui list is “Why does my dialog only open once?”  In this article I’ll explain the problem these users are running into and how to get your dialogs to show each and every time.


All jQuery UI plugins maintain state, such as the current option values, whether the plugin is enabled or disabled, which plugins have been initialized on the element, etc.  This state persists from the time the plugin is instantiated on the element until it is destroyed, either explicitly by the user calling .pluginName('destroy') or by removing the element (or one of its ancestors) via .remove().  Because of this state management, you cannot instantiate the same plugin on an element multiple times, unless you destroy the plugin instance first.

The problem that users often encounter with dialogs is that they try to instantiate a new dialog every time the user performs some action (generally clicking a link or a button).  This is an understandable mistake because at first glance it seems like calling .dialog() on an element is what causes the dialog to open.  In reality what is happening is that a new dialog instance is being created and then that instance is being opened immediately after instantiation.  The reason that the dialog opens is because dialogs have an autoOpen option, which defaults to true.  So when a user calls .dialog() on an element twice, the second call is ignored because the dialog has already been instantiated on that element.


The simple solution to this problem is to instantiate the dialog with autoOpen set to false and then call .dialog('open') in the event handler.

View this example in a new window

jQuery UI - Dialog , , , , , ,