Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Rendering HTML directly #26

Open
mehcode opened this Issue Feb 8, 2013 · 23 comments

Comments

Projects
None yet
Contributor

mehcode commented Feb 8, 2013

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.

Owner

tkellen commented Feb 8, 2013

Target seems reasonable to me.

/cc @tbranyen @sindresorhus thoughts?

Member

sindresorhus commented Feb 8, 2013

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

Owner

tkellen commented Feb 8, 2013

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

Contributor

mehcode commented Feb 8, 2013

Perhaps output instead of type? Good point on target.

Member

tbranyen commented Feb 8, 2013

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.

Member

sindresorhus commented Feb 8, 2013

render: true ?

Contributor

mehcode commented Feb 8, 2013

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.

Member

tbranyen commented Feb 8, 2013

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.

Contributor

mehcode commented Feb 8, 2013

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.

Owner

tkellen commented Feb 8, 2013

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.

👍

Owner

tkellen commented Mar 26, 2013

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

👍 +1 for this option

What ended up happening with this?

👍 +1

Any news about this? 😕

@tkellen tkellen referenced this issue in gruntjs/grunt-contrib-jst Nov 4, 2013

Open

Compile + invoke templates immediately? #35

+1

It would be nice to create static sites, +1

Any news?

+1

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment