Templating API

[jamesplease]

Marionette's template API is potentially more complex than it needs to be. TemplateCache and Renderer are the two abstractions in Marionette for doing things with templates, yet I'm not sure if they're a good idea.

The actions that these two things do are:

1. Resolving templates (templateCache instance)
2. Caching resolved templates (TemplateCache class prop)
3. Compiling templates (templateCache instance)
4. Rendering templates (Renderer)

This works, but it strikes me as an odd systems. In Puppets, the system could possibly be conceptually simpler. Rather than grouping these actions into two arbitrary objects, I will approach each of them as independent things.

Resolving templates

A common default resolution mechanism is to make AJAX requests to fetch templates from the server. LayoutManager and Angular take this approach. In Puppets, I will discourage this to the extent that it won't be as easily configured. Rather, the default will look for the templates at:

Puppets.templates

which is more similar to Ember's approach. This will encourage users to precompile their templates into functions.

Proposed API:

Puppets.resolveTemplate( templateName )

Fetch a compiled or precompiled template by name.

Compiling templates

Compiling templates on the fly will be discouraged, but it will be possible out-of-the-box. The API
will look like:

Puppets.compileTemplate( templateString )

This would be Handlebars by default.

Caching templates

A lightweight Puppets.Cache object should be created. Each instance of Puppets should create a new one for the templates, and store it as Puppets.templateCache.

Puppets.templateCache.get( templateName )

Puppets.templateCache.set( templateName )

Rendering templates

Last but not least is the render method.

Puppets.renderTemplate( templateFunction, data )

[megawac]

Compiling templates on the fly will be discouraged, but it will be possible out-of-the-box. The API
will look like:

Puppets.compileTemplate( templateString )

This would be Handlebars by default.

I would say it shouldn't be supported at all by default. If people are using Handlebars they should be precompiling and using Handlebars runtime in prod

[jamesplease]

If people are using Handlebars they should be precompiling and using Handlebars runtime in prod

I don't disagree with you. The primary reason I want to support it out-of-the-box is for throwing together a quick example app, like a JSFiddle or Codepen.

[megawac]

I would prefer using _ templates by default in that case as they're already a dep

[megawac]

Personally, I would greatly prefer to move this to an extension

[jamesplease]

I'm not sure if the routing system I'm developing will work with Underscore. If it does work with Underscore, then, sure, Underscore could be the default. Otherwise, what do you propose that I do?

[jamesplease]

Personally, I would greatly prefer to move this to an extension

Maybe I'll make this an officially-supported plugin. It would suck for Codepens tho'

[jridgewell]

Why build a system for them? In general, they're just functions that take a data argument. If the user wants X templating system instead, it shouldn't take more than a few lines to get working.

[jamesplease]

Why build a system for them?

What do you mean?

In general, they're just functions that take a data argument. If the user wants X templating system instead, it shouldn't take more than a few lines to get working.

Mhm, mhm. These methods would be really small, for the most part. Examples are already in the repo.

[jridgewell]

What do you mean?

The resolving/compiling/caching/rendering functions. I haven't found a need for it, and it gently nudges people away from templates in one giant HTML file -- I really dislike giant files full of unrelated things.

These methods would be really small, for the most part.

When ever I'm doing really small demos, it's not hard to whip up a jQuery resolver myself.

function template(selector) {
  return template[selector] || (template[selector] = _.template($(selector)));
}

var View = Mn.View.extend({
    template: template('#main-view-template')
});

It's just never seemed necessary to formalize this into anything, especially not into a system as complex as Marionette's. Anything that means less code for the library is a net win, I think.

[jamesplease]

it gently nudges people away from templates in one giant HTML file -- I really dislike giant files full of unrelated things.

Hmmm...I'm not sure if including nothing nudges anyone toward anything, though?

It's just never seemed necessary to formalize this into anything, especially not into a system as complex as Marionette's. Anything that means less code for the library is a net win, I think.

For confident developers, I agree. It's simple enough to write these 10 or so lines of code and move on with things. But not all developers are so confident with coming up with systems like that. Perhaps it's fear of building something that doesn't scale, but on the teams I've worked with, Backbone's lack of opinion only leads to indecision, a feeling of doing it 'wrong,' and an overall loss of productivity.

If I can include a few extra lines of code to alleviate any of that, then I think that that is a really good thing!