A recent change fixed the behavior of `Template.currentData`
and `Template.parentData` in event handlers and helpers.
These are tests for the new, correct behavior.
(The old behavior read the data of the template instance.
The new behavior read the data context around the DOM node
where the event or helper ran)
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.
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.
Make sure inclusions with one path segment like “..” and “foo” (where foo is in the data context) don’t cause the enclosing template to re-render when the data context changes.
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.
We weren’t actually testing that templates removed by control flow (like #each) get their destroyed callback called.
This test should make it to devel regardless of the fate of this branch.
Previously we were using the current component to retrieve the template
instance, but what we actually want is the template instance of the
surrounding component that is a template.
This method returns the parent data context which surrounds the
helper call. This mirrors the effect of {{..}} in Spacebars. So
UI._parentData(2) is equivalent to {{../..}}.
We're no longer going to support these. We supported
them originally on Blaze to make the upgrade process
from Spark easier, but now there's no more need
for them.
Change the unused `viaBackend` flag to `elementsAlreadyRemoved`, and set
the flag in two places: 1. when we remove things from a DomRange
immediately after calling `removeNode`, and 2. when DomRange is notified
that an element has been removed via DomBackend.
The motivation is that re-enabling undocumented animation hooks revealed
that we were trying to remove elements twice: once from `removeNode`,
and once from `nodeRemoved` (via `membersRemoved`).
Internally, Blaze sometimes relies on `UI.render`'s autoruns nesting
within the current computation, but it's often the case that callers
don't want `UI.render`'s autoruns to be stopped when the outer
computation is invalidated. This change fixes a bug in {{#each}}: if
`addedAt` ran inside a `Deps.autorun`, and then the outer computation
was invalidated, the corresponding item would stop updating because the
autoruns set up by `UI.render` would be stopped.
Fixes#2156.
Call UI._allowJavascriptUrls() to enable them again. In the future, we
should have a per-element way to enable this, not a global
configuration, and maybe someday even a similar feature for other
policies (like enabling or disabling inline event handlers).
In `Spacebars.With` we embox the data context. This commit makes
that emboxing happen modulo `safeEquals`. So now if you
{{#with}} over a helper that returns an object, any time
that helper gets invalidated we re-run the computations in the block.
Fixes#2046 (though notably that example mutates the data context
from within a helper, which could lead to other types of unintended
behavior; it's probably in this particular example -- the data context
just gets added properties)
