Unable to serve text! template assets except via the /public folder about requirejs-rails HOT 6 CLOSED

Copying my reply on the requirejs list here

r.js inlines modules referred to with the text! plugin, so that there are no external XHR calls[1] in a production build. The only issue that I see is getting your templates on your assets path, for which there are two approaches:

Solution 1: Add "templates" to your assets path

In application.rb, add:

config.assets.paths << Rails.root.join("app","assets","templates")

This would make "app/assets/templates/hello.txt" available via require(["text!hello.txt"],...);. This path will be picked up by Sprockets, published on /assets in development mode, and copied to the public/assets folder via "rake assets:precompile".

Solution 2: Put "/templates" under "app/assets/javascripts"

Move your templates dir in "app/assets/javascripts/templates". Refer to them like so:

 require(["text!templates/hello.txt"], function (hello_templ) {
   // ... stuff ...
 });

I prefer this solution, since the templates are really dependencies of the javascript code living in app/assets/javascripts. For example, consider if you were to refactor part of your code into a gem. You'd end up with this arrangement in the gem's source, no additional app configuration required:

 vendor/
   assets/
     javascripts/
       <bunch 'o .js or .coffee code>
       templates/
         <templates required by this gem's code>

Either solution should Just Work(tm) with the current requirejs-rails build setup. I'll incorporate a template example into the demo app. If you run into any problems, it's definitely a bug that should be reported.

I know the other common templating library choice among Railers would
be Handlebars. Alex Sexton has done some work to get it to play nicely
with Require.js over here: https://github.com/SlexAxton/require-handlebars-plugin

The hbs! plugin's README claims that it inlines its templates similar to how the text! plugin does, so again it should Just Work. Let us know what happens if you try it out.

[1]: Last paragraph in the section: http://requirejs.org/docs/api.html#text

from requirejs-rails.

FWIW, I like the template module approach you described. That's quite elegant. Seems like it would dovetail nicely with the i18n plugin as well.

from requirejs-rails.

Thanks,

We're currently doing i18n with fnando's i18n-js gem. Right now, I'm manually including the i18n.js file with the application, but we're going to investigate i18n with Alex Sexton's handlebars plugin for require.js. I'll let you know how it goes and what ends up being the best way to keep things clean.

from requirejs-rails.

Hrm, this issue and #37 are interrelated. Looking over the solutions I proposed above, we could run into similar Sprockets path issues that would cause the r.js build to not find templates (even though they were configured onto the asset path) or Sprockets to pick up and try to copy/compile things it should ignore.

from requirejs-rails.

@jwhitley

Thank you so much for posting all this useful info. It saves ton of time for a lot of people.

from requirejs-rails.

All, something like the above already exists in gems like ember-rails. My current setup is a file called templates/all.coffee with a single asset pipeline directive:

#= require_tree .

all.coffee is then treated like a shim in requirejs.yml:

shim:
  "templates/all":
    deps: ["ember"]
    exports: "Ember.Handlebars"

IMHO, requirejs-rails shouldn't try to do too much: There are already solutions for asset pipeline handlebars processing, and if they don't generated AMD, then shims are necessary.

from requirejs-rails.