Using Express Handlebars and Angular JS

Question

Background

I am currently building a website that uses NodeJS for the server, Express Handlebars(Just Handlebars but server side) , and hopefully AngularJS for some client side stuff.

The Problem

AngularJS and Handlebars use the same syntax for templating
{{foo}}
This causes a problem where AngularJS code will be interpreted by Express Handlebars first, which will then throw an error because the data it is trying to pull only exists in Angular not Node.

The Question

Is there a way to get AngularJS and Express Handlebars to work together?

Possible Solutions

• Change the syntax of AngularJS
  • I was looking at BackboneJS and it looks like it is possible to change the syntax. There could possibly be something similar is AngularJS.
• Create a ng helper in Express Handlebars.
  • It would just return its un-parsed content. However I couldn't figure out how to do this.

Solution 1

Your first solution is possible, AngularJS allow to change the start/end symbols of text interpolation like this:

appModule.config(function($interpolateProvider) {
  $interpolateProvider.startSymbol('{[{');
  $interpolateProvider.endSymbol('}]}');
});

Then you could use it in your template:

<div>{[{message}]}</div>

Also see: $interpolateProvider documentation

Hope this helps.

Solution 2

You can always use the ng-bind syntax instead:

<p ng-bind="user.profile.description"></p>
This is identical to
<p>{{user.profile.description}}</p>

From the Angular docs for ngBind:

Typically, you don't use ngBind directly, but instead you use the double curly markup like {{ expression }} which is similar but less verbose.

It is preferable to use ngBind instead of {{ expression }} if a template is momentarily displayed by the browser in its raw state before Angular compiles it. Since ngBind is an element attribute, it makes the bindings invisible to the user while the page is loading.

Solution 3

In order to maintain the AngularJS Style, your second solution is better, Create a helper in Express Handlebars.

References to the Handlebars Web Site: http://handlebarsjs.com/block_helpers.html, you can register a helper raw-helper

Handlebars.registerHelper('raw-helper', function(options) {
    return options.fn();
});

and use it in your hbs template by putting it in a quadruple-stash {{{{

{{{{raw-helper}}}}
<div class="container" ng-controller="AppCtrl">
    Total Members: {{members.length}}
</div>
{{{{/raw-helper}}}}

Solution 4

There is a better way: \{{foo}}. Handlebars content may be escaped in one of two ways, inline escapes or raw block helpers. Inline escapes created by prefixing a mustache block with \ . Raw blocks are created using {{{{ mustache braces. You can see this http://handlebarsjs.com/expressions.html#helpers

Solution 5

I would recommend using the AngularJS's data-binding syntax (what looks similar to Handlebars) and have your NodeJS server simply serve the static AngularJS source code. I prefer to offload the templating onto the client and therefore put less stress on your server, not to mention that AngularJS and other MVC frameworks (my favourite is EmberJS) are great for dynamically building the webpage.

I am a fan of Yeoman and here is a generator for building an Angular project served by NodeJS: https://github.com/yeoman/generator-angular

View more solutions

Comments

[jwimmer]

Why are you using handlebars on the server side rather than jade or ejs? Handlebars/Angular are best on the client side.

[Jake Berger]

@jwimmer what makes Handlebars better client-side? unless something outrageous, it doesn't mean one shouldn't use handlebars server-side

[Jake Berger]

I agree that MV* frameworks are great for dynamically building a webpage, but I think page-instance-specific parts should be served compiled. anything that could change via user interaction -> use client-side templating.

[dudewad]

But, isn't the point of this comment summed up in the first sentence? "Typically, you don't use ngBind directly". ngBind is intended for use against situations where you're experiencing the flash of templated content (FOUC). I would be wary of straying from what the documentation recommends, and this seems pretty explicit in its recommendation to only use thing under these circumstances. I'm more for the accepted answer to this post.

[wayfarer_boy]

This is a better solution than the accepted one as it means you're not veering from the standard Angular double-brackets convention (your Angular code is more modular for use in other projects).

[steverus_snape]

I prefer this solution. The only change I made was to call my helper angular-js - to me {{{{angular-js}}}} better explains it's purpose.

[codeinprogress]

It did not work for me. I am using the documentation where they used // as the new markup. When I do it, it just shows up as is on my page. So something like: <h1>Hello //name// </h1> shows up as Hello //name// on the page

[Tom Pietrosanti]

Also - what happens if the client rendering fails? Serving rendered templates initially will make your page more accessible to a broader audience, not to mention more robust and fault-tolerant.