Oct 18, 2011

Eco Templates in Rails 3.1 Asset Pipeline

CoffeeScript is supported by default in the Rails 3.1 asset pipeline, so you would suppose that support for the Eco library for embedded CoffeeScript templates would be included as well. I did anyway, and was surprised when Rails 3.1.1 treated my new .eco file as a foreigner:

ActionView::Template::Error (no such file to load -- eco


How do I get Rails 3.1 to package my Eco templates?



Add the following line to your Gemfile:

gem 'eco'

Run bundle install and Sprockets (a.k.a. the asset pipeline) is now ready to compile .eco files in app/assets/javascripts to JavaScript.


How do I find and render my Eco templates in my CoffeeScript?



Let's assume you want your embedded template to live in:

app/assets/javascripts/todos/views

If you think you can name your template todo.eco or even todo.js.eco, you're wrong. (Todos is an archetypical JavaScript framework demo app.) Although the template compiles down to a JavaScript function, at the time of this writing, the JavaScript compiled from todo.js.eco will produce a runtime error. Apparently, a JavaScript templating system is required. The easiest solution is to use JST, which Sprockets provides by default. (jQuery Templates are another option, via the sprockets-jquery-tmpl gem.)

Thus,

app/assets/javascripts/todos/views/todo.jst.eco

can be rendered in your CoffeeScript using:

JST['todos/views/todo']()

For a full working example of Eco templates with Rails and Spine, check out Alex MacCaw's infinite scrolling screencast and source.

Update (12/14/2011): Slides from my presentation on Eco at URUG are now online: http://backbonecoffeescript.com/eco-coffeescript-templates

Oct 12, 2011

Backbone.js vs Spine at URUG

I had the opportunity to present last night at the Utah Ruby User Group (URUG, uv.rb section), about two lightweight JavaScript MVC frameworks that I'm very enthusiastic about: Backbone.js and Spine. For those who want to draw lines, the topic is a bit removed from Ruby, although I did serve my examples from Rails 3.1.1, providing a brief asset pipeline intro as well. And I showed and ran a sample of backbone-rails scaffolding. (The slides from the talk are anemic, as uv.rb is more of a roundtable/open format than a lecture.)

I have been using Backbone, in CoffeeScript, in my professional work, and I love it. Spine caught my eye shortly after I started using Backbone, and in my personal time I've been tinkering with it and with Spine Mobile. Both are by Alex MacCaw, who recently published a wonderful book for intermediate JavaScript developers, JavaScript Web Applications, which follows along with the development of Spine. To prepare for the talk, I spent the weekend reading the book and checking out Spine's current CoffeeScript source, as well as adapting some standalone demo apps to use Rails as a backend.

In the end I had four separate Rails apps in which I had scaffolded exactly the same model, Todo, to provide a backend for different versions of the classic Todos sample app. This led to a great moment during the talk in which after clicking around quite a bit in the client, adding and deleting items, I refreshed the page. To my surprise a completely different app loaded in the browser, the one based on backbone-rails scaffolding. After preloading the page for the talk, I had shut down the original app and started the other. This was proof of how well decoupled the front-end app can be: As long as the server provides the correct RESTful json api (and security features notwithstanding), any server will do! After the initial page load, the server is really decoupled from the presentation layer.

After my presentation, another member of the group followed with a demo of testing a real-life Backbone app, with Jasmine specs that were written in CoffeeScript. It was strong evidence of the positive difference CoffeeScript can make in readability.