Unfortunately, these escapes don’t enjoy full “optimization” because template tags are expanded after optimization. To remedy this, we’d have to be more flexible about what TemplateTags can parse into (e.g. a string), or add another pass to the compiler.
Rename inclusion macros (with back-compat) to: Template.dynamic, Template.contentBlock, Template.elseBlock.
Update all uses and mentions of UI in the repo, unless they are there for back-compat or testing reasons.
To do: Run unit tests. Update docs for UI.dynamic. Document Template.contentBlock and Template.elseBlock.
Move Spacebars.TemplateWith to Blaze._TemplateWith. It is the official
way to give a template data, after all, but it’s a little too weird to
make public. Use it in Blaze.renderWithData, even though it doesn’t
seem like it would make a difference.
Unify UI.render/renderWithData with Blaze.render, and add
toHTMLWithData. Publicly, they take a Template or a View.
The View must be unrendered, of course. If given a Template,
constructView will be called. Privately, they take any HTMLJS
extended to be allowed to contain Templates and Views, except
null or undefined, or a function returning extended HTMLJS.
The “data” argument may be a function or a not, as in UI.With
(and unlike the old public UI.renderWithData).
Make Blaze.toText private (Blaze._toText).
This confirms that we can convert complicated templates (including #if, #each, and dynamic attributes) into HTML using Views.
Template#__lookup was moved to View#lookup, since webapp_server is an example of a case where we have lookup but no template!
Next steps: get rid of the “3” after some names, the OLDSTYLE flag, and dead code in the blaze package. Then make Template features like events, `helper`, etc. work.
Making webapp_server work requires #if and #each that work with toHTML. Don’t want to have to write that code just to be able to run client code again.
