Are there any tools or features you think are missing that would better help you develop your webapps?

My initial answer was No, there wasn’t anything I felt was missing. DevTools are awesome, and there hasn’t really been anything I’ve felt like I needed.

Later in the day, I ran into a very common scenario: I was debugging something where I wanted to observe a value at a particular line of code. There are a couple of ways to approach it:

• Drop in a debugger statement or set a breakpoint to stop execution and use the console and/or watch statements to observe the value
• Inject some console.log statements to write the value out to the console

In this case, the console.log approach would be ideal. However, I didn’t have access to modify the code directly, and while I could have used the live editing features, it was also minified code, meaning that live edit was an ugly option.

Thinking back to the survey question, I now had an answer: Wouldn’t it be nice if there was some way to have some sort of action kicked off, breakpoint-style, where I’m not editing the code directly?

I asked some friends, and it turns out, other development environments have a similar concept. Xcode has Breakpoint Actions (as do some other IDEs) which look to be exactly what I wanted. While bouncing this idea around, I realized that I could actually fake it in the browser, right now.

Chrome supports conditional breakpoints. Adding them is easy. First, find the line you want to set a breakpoint on, and click the line number to apply a breakpoint like normal:

Then you right-click on it, and select “Edit Breakpoint”:

You’re presented with your cursor in a field like so, where you can define an expression. If the expression evaluates to a truthy value, execution will break here.

It’s not uncommon to set simple expressions like someObj.id === '1', but I realized that any valid JS expression would be evaluated any time this line was hit – including the console.log statement I wanted to add!

This approach works quite well. Looking over at the console after moving my mouse around a bit on this page (which happens to be the Chrome DevTools Breakpoints page), you can clearly see the added console.log firing:

Since console.log doesn’t have a meaningful return value, the undefined means the conditional breakpoint won’t pause execution, and the code moves on. It’s just like a coded console.log statement, without having to actually modify the code.

Using a conditional breakpoint like this feels horribly hacky, and yet, I love this idea. It achieves the exact goal that I wanted. It’s not elegant, it’s not by design, but it gets the job done, like so many other things in web development.

As an added note, Firebug supports conditional breakpoints in much the same way, and this approach totally works there as well. In both cases, it’s working simply because you’re just evaluating the expression, and only pausing execution if it evaluates to a truthy value.

Hopefully you’ll find this useful at some point! I already have.

⚓ Permalink

For example, event handling is based on this pattern. We take a DOM node and provide it with a callback function so that when the associated event occurs on that node, it has a way of letting us know what’s going on.

1
2
3

document.addEventListener("click", function(e){
  console.log("Document was clicked!");
}, false);

This sort of code is very commonplace, and is one of the more powerful features of JavaScript. When using code that accepts callbacks, we don’t usually think too much of it.

As we create richer applications, we’ll often need to create functions that pass information back to our users. If the information we’re passing back comes from asynchronous sources, it may be beneficial to create functions that that accept callbacks. Because JavaScript functions are first-class objects, you can receive them as arguments, and then simply invoke them.

I prefer Dojo these days, but for simplicity’s sake, I’ll show an example using jQuery, as I suspect that will be more familiar to most people.

1
2
3
4
5
6
7
8
9
10
11
12
13

function getManagers(callback){
  // Kick off our Ajax request for information.
  $.ajax({
    url: "/company/allEmployees.json",
    dataType: "json",
    success: function(data) {
      // Using our callback, provide manager data to our user.
      if (data.managers && typeof callback == "function") {
        callback(data.managers);
      }
    }
  });
}

Notice that in this case, I’m not returning anything from the getManagers function. I’m communicating with my user by invoking the callback they’ve provided to me. This approach is very effective, and people are generally comfortable with using callback-driven functions, so it’s a solid and perfectly valid way to write code. It could also be extended to handle not just a callback for success states, but another one for errors.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

function getManagers(callback, errback){
  // Kick off our Ajax request for information
  $.ajax({
    url: "/company/allEmployees.json",
    dataType: "json",
    success: function(data) {
      // We're breaking the logic to check just for managers first,
      // in order to better facilitate error handling.
      if (data.managers) {
        // We have our data, so invoke our callback.
        if (typeof callback == "function") {
          callback(data.managers);
        }
      } else if (typeof errback == "function") {
        // We have no manager data, so if we have an errback,
        // give it something meaningful to indicate failure.
        errback(new Error("No managers found"));
      }
    },
    error: function(jqXHR, textStatus, errorThrown) {
      // If we have the errback, just give it the error we got.
      if (typeof errback == "function") {
        errback(errorThrown);
      }
    }
  });
}

Using this function is actually quite easy:

1
2
3
4
5
6
7

// Simply call it and provide your callback.
// In this case, I'm not going to worry about errors.
getManagers(function(managers){
  for (var i = 0, l = managers.length; i < l; i++) {
    // Do something with each manager here
  }
});

Writing code that accepts callbacks and uses them is really simple. That being said, callbacks can lead to tightly coupled code. It means that I have to know how I want to process my information at the point of retrieving it. It makes it more difficult to write reusable abstractions of the process used to request data.

Fortunately, there is another approach available to us. Modern JavaScript libraries and toolkits offer us implementations of a concept known as promises. In general terms, a promise is simply an object that represents the value of an asynchronous action. It’s kind of like an IOU for information. It also happens to fit the above scenario quite well.

If you’re using Dojo or jQuery, you already have promises available to you. You can create a Deferred object, which is the mechanism for creating and managing promises.

Working with Deferreds is quite easy. You simply create an instance of the Deferred constructor, and then when your value is ready, you resolve the instance with the value that it represents. If you hit an error state, you can reject the instance. Let’s take the above example and rework it to be using promises instead of callbacks.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

function getManagers(){
  // Create our Deferred instance
  var deferred = new $.Deferred();

  // Then, we'll perform our Ajax request like before.
  $.ajax({
    url: "/company/allEmployees.json",
    dataType: "json",
    success: function(data) {
      // This time though, we'll simply resolve or reject
      // our Deferred instances.
      if (data.managers) {
        deferred.resolve(data.managers);
      } else {
        deferred.reject(new Error("No managers found"));
      }
    },
    error: function(jqXHR, textStatus, errorThrown) {
      deferred.reject(errorThrown);
    }
  });

  // Give our user the promise object that represents
  // our managers.
  return deferred.promise();
}

One key difference above is that we’re actively providing a return value now, whereas in the callback-based version, we didn’t. This object that we’re returning is the promise that we’re giving to our user, and it provides them with the ability to get the information we’re promising, once that data is available.

The Deferred is the mechanism by which I manage the promise. It gives me the ability to create a promise that I provide to my end user, as well as the ability to then fulfill that promise in a meaningful way.

This approach almost feels synchronous. I create an object at the top of my function, and I return it at the bottom. The user doesn’t give me a callback, but I give the user a meaningful object.

The promise object gives your user a then method, which they can then use to attach a callback and get access to the value, like so:

1
2
3
4
5
6

getManagers().then(function(managers){
  for (var i = 0, l = managers.length; i < l; i++) {
    // Do something with each manager here,
    // such as render a list item.
  }
});

There is still a callback in action here, but now it’s being managed in the code that is consuming the information, rather than in the code that is providing it. We’ve effectively decoupled the process of retrieving information from the process of consuming it, which is a huge win for creating reusable code.

There’s also something to be said about reading promise-based code. It feels very natural. I take this action, then I take this other action. It can reduce excessive amounts of indentation, especially when doing a lot of Ajax work at once.

In fact, this approach is so powerful that both jQuery and Dojo already provide a promise as the return value of their Ajax systems. Dojo 1.8’s new dojo/request module is explicitly promise-driven, so requests look like this:

1
2
3
4
5
6
7

require(["dojo/request"], function(request){
  request.get("/company/allEmployees.json", {
    handleAs: "json"
  }).then(function(data){
    // Work with your data here
  });
});

When creating your own modules of code to abstract away the process of data retrieval from data consumption, both callbacks and promises are valid – there’s not one right way to do it. However, using a promise means that you’re giving your users back a meaningful object, and how they deal with the information is up to them. It leads to loosely coupled code, which in turn leads to better reuse and modularization.

Hopefully you’ll consider using promises in your next application! I’ve barely scratched the surface of what makes them awesome. Check out the links below for much more information on promises and Deferreds. Thanks for reading!

• Dojo:
  • Getting Started with Deferreds
  • Dojo Deferreds and Promises
• jQuery:
  • Deferred Object
• Promises/A specification

⚓ Permalink