10 Best Practices for Developing JavaScript Widgets

I’d like to offer updated, practical recommendations to developers who are building widgets. Widgets are essentially a mini-application within your web app that provides specific functionality, for example the map switcher widget included as a screenshot in this post. In May 2010, the OpenAjax Alliance published the Metadata 1.0 specification to define a set of standards for widgets. This was a great start, however in the last two years there have been some significant advancements which render some potions of this spec aged and in need of updating. And, since I’ve run across quite a few widgets in the last several years that seem to consistently have certain problems, this post attempts to provide guidelines for anyone looking to make their widgets significantly more re-usable.

State and Display Properties. All widgets need to make their State accessible via public setters and getters which, at a minimum, includes visible/not visible. Getter properties simply offer developers a way to determine whether the widget is visible or not. So, I add that there also needs to be a way to set the State as visible/not visible. Advanced widgets also need control over inline and block positioning.

Persistence. Widgets need the ability to maintain certain aspects of State and persist between app or browser restarts. For example, primary text fields should be persistent after an end user restarts the browser. The corollary is that there also needs to be functionality to clear persisted data.

View Transitions.Widgets must also persist fully and correctly through view transitions. This has to do with mobile web apps designed to mimic native app functionality that occurs when a user switches between different views within the same app.

Auto-resize. Widgets must auto-resize to their container. The sheer popularity of smartphones and tablets is driving this requirement. For example, when a phone is turned on its side, a widget should automatically fill the new dimensions of the container. If your widget doesn’t auto-resize it will significant limit it’s marketability for mobile devices.

Events. Widgets must have a clearly defined life cycle that is accessible via events. At a minimum this includes when the widget is initialized, after specific actions, and upon an errors. Events need to fire when they are expected to and not before or after. This is especially important for mobile apps where event bubbling, or even CPU/Memory overload, may cause delays in the callback. A properly wired event will fire as expected 100% of the time.

Namespace. Widgets must use name space separation so as to not cause variable and function conflicts. For example, don’t name your widget Class “AppWidget”, a best practice alternative is to call it “com.mycompany.AppWidget”. This also includes protecting your global variables to reduce “leakage” outside of your Classes.

Public Properties and Methods. Only properties and methods that are internal should be kept private. All other properties need to be public.

Documentation and Code Comments. This is an age-old problem. Here’s another way to look at it: in many cases, lack of documentation costs other developers significant lost time, effort and money. The one to two minutes a developer saves by not writing a comment could cost another developer hours, days or weeks of frustration.

Cross-platform compatibility. Clearly document which platforms the widget was tested on. If you haven’t been testing your widgets cross-platform then you need to be. If you only designed your widget for a specific browser, that’s okay as long as it’s documented. At a minimum, truly cross-platform widgets will have been tested on the latest production versions of Firefox, Chrome, iPad/iPhone (Safari), Android (native) and IE.

Debugging. If your widget uses an obfuscated JavaScript library, consider providing either a debug version, or a version that includes public (debuggable) methods alongside the private and obfuscated ones.

Simple Native JavaScript Classes – So simple a caveman could do it.

Among the many things I severely dislike about JavaScript is working with applications that have oodles of global variables, multiple .js libraries and dozens of loosely organized, individual functions. This is a very common pattern (or perhaps an anti-pattern). But it’s a terrible way to code for medium to large projects, especially where you have to share your code. Here’s a highly simplified example:


var someNumber = 2; //Global variable

function add(number){
    return someNumber + number;
};
alert(add(4)); //displays "6"

It’s unfortunate that this pattern is reinforced in authoritative books, blogs and articles. It’s completely pervasive in the majority of examples you see on the web. The downside is modifying, testing and troubleshooting this pattern can be an absolute nightmare. I compare it to building a fragile, multi-level house of cards: one wrong bump and it all falls down.

There is a better way!

So, I offer an easy-to-implement solution: where possible place your functions and properties in Class-like objects and all will be so much better. It’s not quite what you get with strongly-typed object oriented languages like C# or Java, but it works. Besides, if you use this pattern in your project then cats and dogs will live peacefully side-by-side and the universe will be in balance. The best news: this works perfectly fine with plain old JavaScript (POJO). And, if you are using something like jQuery use can use some version of Classes with those too, and I highly recommend it.

Here’s the fundamental pattern of a JavaScript Class:

function Add(){};
var someMath = new Add();

That’s very easy…right?? The advantages are many and include the following:

  • You get a powerful framework for logically grouping functionality. This lends to scalability and ultimately stability in your projects.
  • You can easily extend this pattern using prototypal inheritance.
  • You can take advantage of encapsulation.
  • You can implement inheritance and polymorphism.
Now let’s put this pattern to use. I’m providing two examples here. There are several other syntactical ways of doing this, but for brevity I’m sticking with two. The first example uses a very basic Object to implement namespace-like behavior. I say namespace-like because it’s not a true namespace like in C# or Java. The second example uses the built-in windows Object as a way of passing the namespace information. Click here to download a sample app that demonstrates these concepts.

POJO Class Pattern using Object Namespaces

Here’s an expanded example of the pattern with two levels of namespace separation using a standard Object :

if (!com) var com = {};    //1st level namespace
if (!com.ag) com.ag = {};  //2nd level namespace
if (!com.ag.Add) {
    com.ag.Add = function (value) {
        /// <summary>Demonstrates the plain old JavaScript pattern for classes.</summary>
        /// <param name="value" type="Number">Any number.</param>

        this.getValue = function () {
            /// <summary>Returns the property passed to the constructor.</summary>
            /// <returns type="Number">A number that was passed to the constructor.</returns>
            return value;
        },

        this.add = function (number) {
            /// <summary>This method adds value property + number</summary>
            /// <param name="number" type="Number">The number we want to add.</param>
            /// <returns type="Number">The number passed to the contructor plus this number</returns>
            return value + number;
        }

        //For Visual Studio intellisense cues
        com.__namespace = true;
        com.ag.__namespace = true;
        com.ag.Add.__class = true;
    }
}

And, here’s how to use this class:

var test = new com.ag.Add(2);
alert(test.add(4)); //displays "6"

POJO  Class Pattern using window[] Namespaces

Here is a slightly different version of the pattern that uses the window object, the results are the same:

if (!window["NS"]) window["NS"] = {};

window["NS"].Add = function (value) {
    /// <summary>This class uses addition</summary>
    /// <param name="value" type="Number">The number we pass to the contructor.</param>

    this.getValue = function () {
        /// <summary>Returns the private property called value.</summary>
        /// <returns type="Number">The number passed to the contructor.</returns>
        return value;
    },

            this.add = function (number) {
                /// <summary>This method adds value + number</summary>
                /// <param name="number" type="Number">The value we want to add.</param>
                /// <returns type="Number">The number passed to the contructor plus this number</returns>
                return value + number;
            }

    //For Visual Studio intellisense cues
    window["NS"].__namespace = true;
    window["NS"].Add.__class = true;
}

Here’s an example of how to use this class:

var test = new NS.Add(2);
alert(test.add(4)); //displays "6"

You are probably wondering about the funky xml comments. That’s for Visual Studio 2010’s built-in intellisense. I think but I’m not 100% certain that these work with Visual Studio Express as well. If you know for sure then please drop a comment. Notepad++ and other tools are okay for small projects but you can thank me later when you use this Class pattern along with built-in intellisense for any project that involves more than a dozen or so functions. And that’s not all – you can also see intellisense across different .js libraries. It’s all about productivity and ease-of-debugging. And, everyone will thank you when they have to re-use your code.

I’ve also attached a screenshot below to show you what the Visual Studio intellisense looks like. Also note in this example, the physical file, Add.js, in in the directory /scripts/com/ag/Add.js and I’m writing code in index.html which is at the root directory. How cool is that?!

 References

Sample application that demonstrates the Class concepts

Douglas Crockford’s [awesome] JavaScript Blog

Visual Studio JavaScript Intellisense Revisited

Creating Advanced [JavaScript] Web Applications with Object Oriented Techniques

Object Oriented Programming in JavaScript

Write Object Oriented JavaScript Part 1

The Format for JavaScript Doc Comments (Visual Studio)