Rendering HTML directly

[mehcode]

I'd like to add support for grunt-contrib-handlebars to allow it to render handlebars templates directly to HTML.

Thoughts on option names ?

handlebars: {
  options: {
    target: 'html',  // Defaults to 'js' ?
    data: {
      // Context goes here
      foo: 3251
    }
  }
}

Something like the above.. unless you have a better idea for the target name.

[tkellen]

Target seems reasonable to me.

/cc @tbranyen @sindresorhus thoughts?

[sindresorhus]

Sure, I would probably go with type though, since target already is described as task targets, might be confusing, I dunno.

[tkellen]

Good point, overloading the target term hadn't even occurred to me.

[mehcode]

Perhaps output instead of type? Good point on target.

[tbranyen]

How many other types are there? It's not really HTML you're rendering, it's text. I'd say this is a precompile vs. render flag.

[sindresorhus]

render: true ?

[mehcode]

The only reason I was thinking type or target was because of my https://github.com/concordusapps/grunt-haml project that allows a target of js, coffee, or html.

[tbranyen]

But JS and Coffee in this case represent means to the same end, once the coffee is converted to JS they are both precompiled templates, while what you're requesting sits outside of that as completely rendered templates. These feel distinct enough to be treated separately.

Maybe:

// Precompile to JS.
precompile: {} // or true

// Precompile with options.
precompile: {
  coffeescript: true
}

// Render to text (default to html extension).
render: {} // or true

// Rendering with options.
render: {
  ext: "html"
}

This isn't really standard for Grunt, but maybe something along these lines. I could foresee wanting both precompiled and rendered.

[mehcode]

But JS and Coffee in this case represent means to the same end

True but in order to properly compile coffee-script and remove as much bloat (all of the duplicate helpers from it, etc.) you need to intelligently concatenate all of your coffee-script before compiling. Not that I do this yet. However as coffee-script provides no way to remove these helpers on a per-file basis this kind of thing will eventually be required as some quick testing on my end shows a 15% reduction in final output size between compiling ~50 coffee then merging or merging then compiling 1 coffee. But that's also not really related to this. I just brought it up as I want the config syntax between this and grunt-haml to be the same-ish.

With that said I'd probably prefer a precompile flag like the following (that way I could extend it in grunt-haml to achieve the coffee thing):

// Precompile
precompile: true // default

precompile: false // render the html

precompile: {
  output: 'js' // default
}

precompile: {
  output: 'coffee'
}

precompile: {
  output: 'livescript'
}

---

On a completely unrelated note... has any thought about doing grunt-contrib-template? There is a consolidate task out there but it doesn't do pre-compilation.

[tkellen]

There have been several attempts (some by me) to smash every templating engine into the same round hole, but it always winds up being a monolithic mess of configuration options to support each templating engine's unique features. That said, taking the output of a precompiled template and wrapping it with an AMD define call, or assigning it to a JST namespace could definitely be generalized into grunt-lib-contrib. I'd love to see something like that.

[outaTiME]

👍

[tkellen]

there is some work being done on gruntjs/grunt-contrib-pug#19 that could give us a coherent standard for implementing this sort of thing across all of our templating tasks.

[tnguyen14]

👍 +1 for this option

[pspeter3]

What ended up happening with this?

[mitsuruog]

👍 +1

[oswaldoacauan]

Any news about this? 😕

[paparomeo]

+1

[johannesjo]

+1

[rludgero]

It would be nice to create static sites, +1

[rludgero]

Any news?

[tschiela]

+1

[rludgero]

Hello everybody!
Someone is working on it?
Any news about this?

[matteoantoci]

+1