7 Tips While Working With JavaScript Templates

Open Source 25 Mar , 2013  


Simple-JavaScript-CalculatorMaybe you don’t need them for simple web apps, but it doesn’t take too much complexity before embracing JavaScript templates becomes a good decision. Like any other tool or technique, there are a few best practices that you should keep in mind, when using templates. We’ll take a look at a handful of these practices in this tutorial.

1. Underscore for Simple, Handlebars for Complex:

If the project is relatively simple, you can use Underscore.js. For the most part, this library offers functional programming utilities, but it does have a _.template method that couldn’t make things easier. By default, it uses the ERB-esque <%= %>delimiters, but that can easily be modified. The beauty of this solution is that any project that requires templates will likely have Underscore loaded already, simply due to its sheer general usefulness.

If you need something with a bit more zest, might I recommend Handlebars? With many useful block expressions (such as #each for looping and #if for conditionals) and the ability to register your own helper functions, Handlebars will give you everything you need to create even the most complex of templates.

2. Create Template Helper Functions:

There will be times, when the data that you are inserting into a template won’t quite be formatted in the way you prefer. In these situations, you’ll need to create custom functions to format it. If you’re using something like Handlebars, you can easily register a helper function; but other solutions, like Underscore, don’t offer that functionality. You’ll have to roll your own.

3. Store Templates in Their Own File:

All JavaScript templates obviously start out as text. The most popular (and natural) place to store them is within your HTML document – usually in a script tag with an alternate typeattribute, so that the browser doesn’t attempt to execute them. It’s fairly easy to grab the innerHTML attribute of the scripttag and pass it to the template-creating function, when you’re ready.

However, this isn’t the only way to do it; in fact, it might not be the optimal way. There are several alternate solutions that might be better, especially in more complex scenarios.

4. Precompile Your Templates:

If you think about it for a second, there’s some extra work done by the browser every time you create a template. Usually, that template starts out as a string that you pass to a template-creating function. That function returns another function, which you can pass the data to and receive HTML from. The extra work is the “creating-the-template-function” part; there’s no reason why this can’t be done before the JavaScript is sent to the client. Preferably, you could put add this work to your build process, along with minifying your CSS and concatenating your JS.

5. No Evaluation in Templates:

It’s since become a best practice in the community: no evaluation in templates. Of course, interpolating variables is, strictly speaking, evaluation, but what I’m more referring to here is logic code. You can put whatever JavaScript you’d like inside of the delimiting tags, but it can easily get out of hand. We all know that it’s considered a best practice to keep your HTML, CSS, and JavaScript separate; this makes it easier to keep track of the code and spot errors, when necessary.

6. Bind Data to the Templates:

This won’t always be applicable, but, in some cases, it can be really helpful to make your templates update automatically, when the data they are displaying changes. I like this idea a lot, because it allows even the UI of your application to be completely data-driven: when a model attribute updates, the UI updates with it. This is the basic principle behind tools, like Knockout.

While you could probably roll this functionality on your own without too much trouble, all the popular frameworks have it built in. For example, in Backbone, a template’s initializefunction might include some custom event listeners…

7. Simplify Your Templates:

If you aren’t careful, very quickly, your templates can get out of hand and become unwieldy. This is why it’s always a good idea to limit your templates to a reasonable size. If you make them too large, they’ll be more difficult to update, and won’t allow for a good separation of the code. On the other hand, if they’re too small, they’ll cost too much for what they bring, and will subsequently slow down your app.

Don’t Use ’em if You Don’t Need ’em:

Finally, remember that JavaScript templates is just one more tool in your box; and, sometimes, it simply isn’t the right one for the job. Don’t use templates where you don’t need them. Use your head: there may be other situations, when a template is not the best tool, So enjoy it 🙂

, , ,