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.
Also improve info strings on blaze and ui
Not in this commit:
* Change all uses of `ui` package to use `blaze`
* Change all references to UI symbol to Blaze
* Change docs accordingly
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).
The “rendered template” returned by UI.render and taken by UI.insert
and UI.remove is now a View (soon to be UI.View) instead of a DOMRange.
The pattern UI.insert(UI.render(Template.foo), div) is exactly the same.
The pattern Blaze.render(Template.foo).attach(div) no longer works.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
* `Template.__create__` is now `new Template`
* `Template = Blaze.Template`
* `Template` is a constructor function
* `Template.foo instanceof Template` (but keep `Blaze.isTemplate`)
* No more `Blaze.runTemplate` (use `template.constructView`)
* `constructView` instead of `__makeView`
* template objects have `__kind` and `__render`
* No `__viewName`, `__templateName`
* `Template.__body__` is now `Template._body_` (and renamed methods)
* No `Template.__lookup__`, instead `(name in Template) && (Template[name] instance of Template)`
* `Template.__define__` replaced by `Template.__assign(name, template)`
Regression introduced by the CSS watching code (specifically, f230eba62)
by the sourceIsWatched check. We need to be able to tell the difference
between "source handler didn't do anything because there was an error"
and "source handler didn't do anything because it's web-specific and
this is an os arch".
A simple fix would have been to interpret compileStep.error as
"sourceIsWatched = true", but I didn't think of that until after doing
it the slightly more complicated but more precise way :)
Also, ensure that if the runner rebuilds the client and there's an
error, it properly kills the app process (and the watchers and the
keepalive interval, etc).
