The renames of packages ui -> blaze, deps -> tracker,
livedata -> ddp worked fine when a package or an app
dependened on the renamed packages. But if there was
a weak dependency (say `api.use('ui', {weak: true})`)
then:
(1) `Package.ui` would be null (since it's not in
meteor-platform)
(2) Even if your app added 'ui' explicitly, the 'ui'
package didn't export any symbols.
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
DOMRange#setMembers was causing DOMRange#onAttached callbacks to get called, masking a bug in onViewReady where DOMRange#attached was misspelled DOMRange#isAttached.
You don’t get the “wait for attached” behavior from Blaze.View anymore, you just get a plain onViewRendered callback. No onMaterialized. The template “rendered” callback implements the wait-for-attached and wait-for-afterFlush parts.
Also, if a template somehow re-renders, it won’t get extra event handlers now. And if it re-renders before being attached, something sensible will happen (like all the calls of the rendered callback will be saved for onAttached).
view.isCreatedForExpansion and view.isInRender become private.
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)`
UI.render and UI.renderWithData now return a DOMRange.
We've never quite documented what the return value of
these functions is, other than "you can pass it to
UI.insert", which is still true.
Also ported the tests by moving them into the spacebars-tests
package, so that they use a template rather than the
component/htmljs API. This has the added benefit of
making the tests less brittle to changes in internals.
Biggest fix is that event data was wrong; when binding “this” for an event handler, we didn’t have a pointer to the current template, just a pointer to the prototype (i.e. the object Template.foo itself), and we were using that.
DomRange now never removes elements except through the removeElement UI hook. If you write a hook that prevents removal, teardown still happens (e.g. templates stop updating).
This code also provides the basis for stopping updates to part of the DOM by triggering teardown without removal.
Before, DomBackend.removeElement would both trigger teardown and actually deparent the element. Now we have DomBackend.tearDownElement, which just triggers the jQuery teardown (which in turn triggers finalization of DomRanges that have been inserted in the DOM tree).
The flag to {node,members,range}Removed is now named “alreadyTornDown” and documented. Its purpose is to prevent redundant teardown walks through the DOM.
