Thinking about a Backbone commanding pattern

Lately I have been working with a commanding pattern and CQRS wiht sever-side code. In the context of a rest api, IMO a commanding pattern fits quite nicely. Lets take the example of marking a product as active.

Traditional CRUD Rest API: PUT /products/123 {active: true}

Commanding Rest API: POST /products/123/activate

But this isn't the full story. Usually, when use the PUT verb, you have to send the entire entity. When you send the POST verb to send the activate command, it is much more concise and expressive to what you are actually doing. But the POST verb is intended to create entities you say? Well, aren't we just CREATING a command?

This paradigm of using the POST verb to create commands is really quite slick. It creates expressive and meaningful endpoints. For me, there was only one problem: My project is heavily invested in backbone. Backbone is designed to communicate with a rest api to Create, Update, and Delete entities. I've been thinking about a way to bridge this gap between client side CRUD operations and server side commanding operations.

There are some examples of commanding pattern in JavaScript. These examples, in my opinion, are a little heavy handed. I'm not looking to create a command bus in java script. When I'm working with Backbone objects, I usually already have a collection or model in which I am trying to manipulate. I’m thinking about extending Backbone to allow for commands to be sent. Here is some pseudo code for what I’m thinking:

var Commanding = {
    execute: function (command, context) {
        var self = this;
        this.trigger('command before:' + command, [self, command, context]);
        return $.ajax({
            url: _.result(this, 'url'),
            method: 'POST',
            data: context,
            always: function (data, status, xhr)
            {
                var events = 'command: ' + status + ' ' + status + ':' + command;
                self.trigger(events, [self, command, context, xhr, data, status]);
            }
        });
    }
}

_.extend(Backbone.Model.prototype, Commanding);
_.extend(Backbone.Collection.prototype, Commanding);

exmpleModel.execute('activate');
//triggers commdand and before:activeate events
//sends POST /products/{id}/activate ajax request
//triggers command:success success:activate events
//returns xhr object, so you can chain fail success/failure callbacks

I have not yet implemnted this patern, but I think this might be the best way to bridge CRUDy Backbone and CQRS rest api.

Tags: backbone, js, ddd, commanding, rest api, webdev

Making The Case For Client Side Templates

Context: We are building a single page web app with backbone. The Backbone.View object has a render method. The intent of the render method is to provide a place for the developer to render the view, by whatever means the developer wants.

Question: Why use client side templates? The reason is simple: in the javascript world, you have 3 options for building HTML:

  1. Concatenate strings
  2. Build DOM programmaticly
  3. Use a template engine

Let's pose the following scenario: Given an array of products, loop through and display the products.

var product = [
    {name: "Chicken Strips", product_nbr: "abc123"}
    {name: "Cow on a stick", product_nbr: "97208"}
];

The following 3 code blocks are psuedo code for what the render function might look like:

Concatenating Strings

var str = "<div><h1>Products</h1>";
for (i in products) {
    str += "<ul>;
    str += "<li>Name:";
    str += products[i].name;
    str += "</li><li>Nbr:";
    str += products[i].product_nbr;
    str += “</li></ul>”;
}
str += “</div>”

this.$el.html(str);

Building DOM (jQuery)

var $div = $("<div>");
$div.append("<h1>Products</h1>"
$.each(products, function () {
     $div.append(
        $("<ul>").append($("<li>").text("Name: " + this.name))
                 .append($("<li>").text("Nbr: " + this.product_nbr));
    );
});

this.$el.append($div);

Templating (Twig.JS)

this.$el.html(twig({ ref: "products" }).render({products:products}));

Products Template

<div>
   <h1>Products</h1>
   {% for p in products %}
      <ul>
          <li>Name: {{ p.name }} </li>
          <li>Name: {{ p.product_nbr }}</li>
      </ul>
  {% endfor %}
</div>

Concatenating strings gets ugly really fast. Building DOM is the least verbose, but it is error prone and incredibly difficult to maintain for anything but the simplest DOM structures. Just imagine changing the UL to table rows. It would not be fun. Templating is the most concise, easiest to read, and easiest to maintain. In this example, there is some bootstraping code that isn't shown for loading the templates from an external source (this is a topic for another post.) By loading templates as needed, you can keep your JavaScript code clean and concise. No need for your render method to be polluted with a bunch of DOM logic. Backbone.View then becomes a wrapper around your templating engine with functionality for listing to model changes and user events.

A Few Templating Engines

Disclaimer: Things move really fast. These template engine options may not be the best options out there right now. These are just the ones I have evaluated.

My Requirements for a Templatint Engine are

  1. Some logic such as loops and conditionals
  2. Flexible loading from external files or inline strings
  3. Simple syntax

Below are a few of the Templating Engines I have evaluated and how to they work to render HTML.

Underscore.JS Templates

Because Underscore.JS is a dependency of Backbone, it ships with Backbone. It is pretty simple and powerful. _.template takes the template as a string and returns a template function that will then take the variables for template and return the rendered template.

var compiled = _.template("hello: <%= name %>");
compiled({name: 'moe'});
// returns "hello: moe"

In order to get this to work in practical way inside a larger application, you will need a way to load the initial template strings. You could load the templates via ajax(not shown here) or have them inline using a script tag:

<script type="text/template" id="template-hello-world">
    <h1>Hello: <%= name %></h1>
</script>
var compiled = _.template($("#template-hello-world").html());
compiled({name: 'moe'});
// returns "hello: moe"

Conditionals and loops are achieved using JavaScript. While this is powerful, it really can be a pain in the butt:

<script type="text/template" id="template-products">
    <div>
       <h1>Products</h1>
       <% _.each(products, function(p) { %>
          <ul>
              <li>Name:  </li>
              <li>Name: </li>
          </ul>
       <% }); %>

       <% if(someConditional) { %>
           Print some string
       <% } %>
</script>

While using javascript inline is powerful, it isn't very easy to read and can get messy quick.

Mustache

Mustache is pretty neat. It has implementations in a lot of languages. Its syntax is relatively easy to read. You can load the templates in similar fashion as our first example:

<script type="text/template" id="template-hello-world">
    <h1>Hello: {{ name }}</h1>
</script>
var templateString = $("#template-hello-world").html();
Mustache.render(templateString, {name: 'moe'});
// returns "hello: moe"

Looping is little loopy (no pun intended):

<script type="text/template" id="template-products">
<div>
   <h1>Products</h1>
   {{#products}}
      <ul>
          <li>Name: {{ name }} </li>
          <li>Name: {{ product_nbr }}</li>
      </ul>
   {{/products}}
</div>
</script>

Loops are a nice feature. But what about conditionals? The docs say:

We call it "logic-less" because there are no if statements, else clauses, or for loops. Instead there are only tags. Some tags are replaced with a value, some nothing, and others a series of values.

So NOOP! No conditionals for you! It does make up for this by allowing you to pass in a function as a variable.

Handlebars

Handlebars.JS Is also a very good option. Again, Hello World:

<script type="text/template" id="template-hello-world">
    <h1>Hello: {{ name }}</h1>
</script>
var templateString = $("#template-hello-world").html();
var compiled = Handlebars.compile(templateString);
compiled({name: 'moe'});
// returns "hello: moe"

Like Mustache, Handlebars uses the a tag based system for loops and functions, but has conditionals build in:

<script type="text/template" id="template-products">
<div>
   <h1>Products</h1>
   {{#with products}}
      <ul>
          <li>Name: {{ name }} </li>
          <li>Name: {{ product_nbr }}</li>
      </ul>
   {{/with products}}
   {{#if someConditional}}
        render something
   {{/if}
</div>
</script>

Twig.JS

Twig.JS is a JS implementation of the PHP Templateing engine Twig. Twig.JS implements a subset of the PHP Twig features, but all the necessary ones are here. Like the PHP implementation, you can have custom filters, functions and tags. If you already use Twig for PHP templates, Twig.JS is a no brainer.

<script type="text/template" id="template-hello-world">
    <h1>Hello: {{ name }}</h1>
</script>
var templateString = $("#template-hello-world").html();
var compiled = twig({ data: templateString });
compiled.render({name: 'moe'});
// returns "hello: moe"

Summary

In a large JavaScript application, templates make the presentation code easier to maintain and easier to read. Most template engines are very similar but there differences are notable. Take time to evaluate your options and pick the best one for your project.

In another post, I will provide details on how to abstract away the differences in different templating engines in your Backbone.View.

Tags: backbone, js, templates, twig.js, webdev