View Helpers For Underscore Templates

Underscore’s template engine lets you run any arbitrary JavaScript code that you want, within a template. You could write an entire JavaScript application within an underscore template if you want. But this is a really bad idea. Templates should be clean and simple. Some people go so far as to say “logic-less templates”, but I honestly don’t think that’s reasonable. I also don’t think it’s reasonable or responsible to have a bunch of JavaScript code littered throughout the template, though.

Fortunately, it’s easy to build helper methods for Underscore templates (and they end up looking a lot like Rails view helpers).

Logic In Templates: A Bad Idea

On a client project recently, I had a JavaScript object that needed to be bound to my template. The object looked somewhat like this:

I needed to take all of the “addresses” and find each specific address within the array, by name, so that I could get the right information in place at the right time in my template.

The first pass of code that I wrote to do this, looked like this:

And this worked, but it’s a bad idea. I have a lot of duplication in this template and I have a lot of logic and processing of data in the template, too. This is going to make for a very painful setup when it comes to maintenance – especially if / when I have to change how the address is looked up.

View Helper Methods: A Better Idea

In asking around on twitter for some suggestions on how to clean this up, I received several responses. Out of everything that everyone said, though, I liked the response I got from DaveTheNinja because of it’s simplicity.

The basic idea is to recognize that the data I send to my template is a JavaScript object. Since this is an object, it can have methods. If I can have methods on my object, why not put methods on it as view helper methods?

The helper method – “getAddress” – is pretty much the same code. But now it’s consolidated in to a single location and I’m able to give better formatting for it which makes it easier to read and understand.

You can also see that I’ve kept the data separate from the objects until just before rendering the template. I’m using Underscore’s “extend” method to copy all of the methods from my “viewHelpers” object on to my data object.

Then when I pass the data object to my template, I can call my “getAddress” method like this:

And we’re done! I now have view helper methods that I can call from within my templates.

Using This With Backbone

I use this technique with Backbone a lot. The code that I showed above is really no different than what I do with my Backbone views, either. When you get to the point where you need to render your template, just extend the view helper methods on to your data before doing the actual rendering:

Using This With Backbone.Marionette

I’ve added this functionality in to Backbone.Marionette as well. ItemView, CompositeView and Layout will all look for a `templateHelpers` attribute on a view definition. If it finds it, it will mix that object in to the data that is used to render the template:

You can specify a reference to the viewHelpers object as shown in this example, provide an object literal as the templateHelpers directly, or specify a function that returns an object with the helper methods that you want. For more information see the documentation for Marionette.

Other Template Engines

This basic technique will probably work with other template engines, too. Some engines like Handlebars, though, have this idea baked in to them directly. But if you’re using Underscore’s templates, then this is a good way to keep your templates clean while still providing the logic you need.