This way we don't get a stack overflow when materializing nested
Views. Certain browser/OS combinations seem to have particularly
low budgets (especially Firefox/Windows apparently).
Verified by running https://github.com/mxab/meteor-call-stack-exceed
on Chrome/Mac. Nesting limit used to be about 160, but now you get
unlimited nesting (tried up to 10,000, which renders in about 7-8
seconds).
Tested for correctness by running all package tests.
The blaze package defines Blaze.Template, not Template, and should find
it there.
(Apps tend to put `Template = Blaze.Template` globally on the client via
templating package, but that's not guaranteed, and doesn't happen on the
server.)
A previous change decoupled "current view" from "current template instance".
The code made sure to preserve "current view" explicitly within
`this.autorun`, but now we need to do the same for "current template instance"
Prior to this change, a dependency was registered on
`Template.instance` when wrapping a helper, rather
than when it is called. This caused templates to get
re-rendered more frequently than necessary as caught
by a test failure, and probably many other bugs.
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.
