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.
If you Blaze.remove a View that is a template rendered by Blaze.renderWithData, or included with an implicit “with” as in `{{> myTemplate someData}}`, Blaze will now remove the DOM of the template, and also remove the implicit “with” (in both cases).
As background, Blaze.remove only works on Views that were attached directly under a DOM element, not inside another View. Blaze.render always attaches the resulting View directly under a DOM element, but Blaze.renderWithData creates a “with” View around the template View. Previously, you could Blaze.remove the “with” View (which is returned by renderWithData), but if you got access to the template’s View some other way and tried to remove it directly, nothing would happen. Now, the correct thing happens (the View is destroyed and the DOM is removed).
In the future, we should consider whether Blaze.remove should work on arbitrary Views, not just Views attached under a DOM element.
Encountered this bug when I tried to update an app that was generating Blaze warnings about the deprecated old-style helper to a 0.9.4 RC. The problem is that the type of the string `'Log'` is being checked rather than the value of the `Log` variable, which obviously returns true, and then the code breaks on the `&& Log` check, which is undefined.
with back-compat.
The “old-style” syntax is `Template.foo.bar = …` instead of `Template.foo.helpers({bar: …})`.
Properties of back-compat to test: You can replace an old-style helper (overwrite it). You can delete an old-style helper. We don’t have to support these capabilities, but we used them both in our test code, so apps probably do it too.
We print a deprecation once per helper. This leads to a lot of warnings! It’s helpful for porting, though developers who for some reason don’t want to port yet may want a way to disable them.
`spacebars-tests` pass.
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.
By choosing names like Template.registerHelper(…) and Template.instance() (instead of Blaze), we can separate the “Templates” section and the “Blaze” section of the docs.
