Everything is about context.

How many times have you seen or worked on web applications where dozens of XMLHttpRequest objects were used to make AJAX requests? Pretty much any web application, right? What about doing the right thing when those requests fail? Not so many perhaps, but I’d be willing to bet you still worked on quite a few where at least 404 or 500 status codes were handled. That’s still not good enough if you are handling them every time, whenever you made a request.

Maybe something like the piece of pseudo-code below.

$.get('/api/cats').then(meow).fail(MEOWWW);

A much better alternative is to centralize this kind of error checking, so that the rest of the application can live happily ever after without a worry in the world about status codes other than 2xx. That’s where measly comes in. Measly allows you to easily define a layered hierarchy for your components. It’s able to handle requests on any of these layers, or on the request itself.

To get you started, the first thing you’ll need to do is create a layer whenever a view or partial view is rendered. If you were using Taunus, then that would be pretty easy. Taunus let’s you hook into the rendering engine and listen for views being rendered. You can use this hook to create a measly layer associated to each view’s container.

taunus.on('render', function (container, model) {
  model.measly = measly.layer({ context: container });
});

Once every view has it’s own measly layer, you could create a global hook to render error messages in the context for the layer where the failed request originated. Note that if I created the hook on model.measly instead of just measly, it would’ve only affected requests on an specific view.

The render method shown below uses some code written in Dominus, a jQuery-like library, to render the error messages. Since we’re using the context of the partial where the request originated, the error will be displayed close to whatever the user was interacting with, at the top of that partial view. However, you could easily change the rendering logic if you wanted to.

measly.on(404, render);

function render (err, body) {
  var context = $(this.context);
  var messages = $('<ul>').addClass('vw-validation');

  $(body.messages.map(dom)).appendTo(messages);

  context.find('.vw-validation').remove();
  context.prepend(messages);
}

function dom (message) {
  return $('<li>').text(message).addClass('vw-validation-message')[0];
}

Note that this approach to error reporting in the DOM forces you to have some sort of convention when it comes to JSON responses. That is a good thing, though!

You’re now able to make requests through measly and never again worry about failure responses. The example below shows how you could do that with access to the model, presumably in a partial view controller.

function (model) {
  $('.ca-save').on('click', function () {
    model.measly.put('/api/cats', model.cat);
  });
}

What other kinds of conventional tactics would you apply to your front-end architecture?