Server-side template rendering with Handlebars & HandlebarsAssets.

[wideopenspaces]

This is built on the work of @deepak, @zohararad, @AlexRiedler and @variousauthors in #46. Only the controller/responder code is my own.

I'm putting this up mainly for feedback and improvement, and perhaps paving the way for inclusion in the main gem or development as an enhancement gem.

As far as I am aware it only supports get requests on a single resource (i.e. 'show') at the moment; I have tested that.

It adds support for the use of respond_with(@object) style rendering when paired with respond_to :hbs (or :handlebars), eliminating the need for either of the following cases as implemented in #46:

respond_to do |format|
   format.html { render template: '...', locals: @object.to_hbs }
end

respond_with(@object) do |format|
   format.html { render template: '...', locals: @object.to_hbs }
end

It does require a :to_hbs or :to_handlebars method on your resource, as it is used by ActionController::Responder to convert the resource.

It supports responding to multiple mime types (respond_to :hbs, :json) within the same controller and action, as well.

I don't know if it works with hamlbars or slimbars yet, but I'm interested in implementing that support, as I will likely need it in the near future.

No tests, but I'll see what I can do about adding tests for the code as soon as possible.

Finally, I tried to keep the server-side code as separate as possible. It is not loaded by default when the gem is included in a project, and needs to be required using require 'handlebars_assets/server' and included into a controller before it fully activates.

[AlexRiedler]

I did just update my tilt_action_view repo; so I might replace the code with that after (as it is just a setup of a module that I could put in the same server file).

Runtime performance is a good idea to verify as well (I have not bothered checking); there is clearly some improvements that are possible to do (e.g. check if we have already compiled that source before -- remember about local dev though for changes!)

The other kicker I would want to do is add ActionView helpers to the regular templates (which I assume is a problem you will run into soon).

[wideopenspaces]

At least in development, precompile:assets generates a file in app/assets/templates/**/{action}.jst.

Knowing the rules of naming and the location of the compiled file, we could probably do a simple File.exist? on the name we assume it will have, and compile using that if it exists. I'd want to expose a configuration option whether or not to use cached compiled files in development, however, and default it to false.

I don't know if the individual files are generated in other environments. That would be a blocker.

Another possible option is to cache the compiled template ourselves. It still results in duplication of effort between the two pipelines, but would avoid template recompilation on subsequent requests.

My preference is to use the Rails cache to store it, rather than the filesystem.