Compile + invoke templates immediately?

[cowboy]

There are 2 main use-cases I see for "javascript" templates:

1. Compile template files into JavaScript functions for use on the client. These templates will be namespaced and combined into a single .js file.
2. Compile template files into JavaScript functions for use on the server. These templates will be run immediately, with the output being saved into .html files.

This plugin already does 1, but what about 2? In my example, I'm already using lo-dash templates in the client via requirejs plugin, but I don't want to use Jade for the app's index.html page. I also want to use lo-dash templates.

So, in my project Gruntfile, I created this "tmpl" task, but it seems a little redundant for this to be a separate thing.

grunt.registerMultiTask('tmpl', 'compile lodash templates to html files', function() {
  var _ = require('lodash');
  var options = this.options({
    data: {},
    templateSettings: null,
  });
  var origTemplateSettings = _.templateSettings;
  this.files.forEach(function(f) {
    var src = grunt.file.read(f.src[0]);
    if (options.templateSettings) {
      _.templateSettings = _.extend(_.templateSettings, options.templateSettings);
    }
    var html = _.template(src, options.data);
    grunt.file.write(f.dest, html);
    _.templateSettings = origTemplateSettings;
  });
});

Is there a place in grunt-contrib-jst for the "2" behavior?

[tkellen]

Yes, there is definitely a place for it. We were close to settling on a standard across all templating tasks before I disappeared into the woods. The relevant conversation is here: gruntjs/grunt-contrib-handlebars#26

[cowboy]

Ok, well it seems like this should happen for grunt-contrib-handlebars and grunt-contrib-jade, but in a consistent way. So let's discuss the solution for all 3 plugins here.

Some questions:

1. Is it as simple as compiling one input template file + some data + optional settings into one output file?
2. Do we need to worry about partials? If so, how do we handle this, by specifying a single input file + a baseDir where the partials will live?
3. What about an option render that, when set to true, renders the template with the specified data object?

/cc @tbranyen @shama @sindresorhus @vladikoff

[cowboy]

I'm guessing that if a plugin needed partials, we'd already be specifying some kind of baseDir option. Right?

[tkellen]

Unless I am misunderstanding you, a baseDir would be meaningless for jst/handlebars, as they don't have the concept of file io built in like jade does.

[vladikoff]

/cc @oswaldoacauan @mitsuruog @pspeter3 @tnguyen14 @outaTiME @mehcode pinging a few devs who were interested in this feature and hopefully have some input.

[cowboy]

@tkellen correct, but in case we ever added another templating plugin that supported partials, it seemed like a good "standard" option to define.

[cowboy]

For example, I see a few options in grunt-contrib-handlebars for dealing with partials, but they seem to be a bit ad-hoc, and confusing to me. Could configuring partials support for grunt-contrib-handlebars and grunt-contrib-jade be done in more general ways?

[mehcode]

Something to perhaps reference. We have implemented static compilation / partials in https://github.com/concordusapps/grunt-haml. From a pull request we also have static compilation to JS variables (basically take the HTML and assign them to JS variables in a big file) -- seems a bit weird to me but I don't use server-side templates too much.

If anything, I'll make sure to watch this space and update the plugin to conform to whatever is decided.