This included removing some internal version constraints. It would be
nice if package A could say "use B@2.0.0" (when both have changed), but
when they're both in the release, we need to make a release that has a
B@2.0.0-rc in it, which doesn't match that constraint. Fortunately,
constraints aren't necessary within a release anyway.
Fill in all packages without README.md files with a short
README.md mentioning that this is an internal Meteor package.
Break up the top paragraph of a couple of existing README.md
files to be proper long description.
There is more work to do here, involving line wrapping and the like.
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.
