Move Spacebars.TemplateWith to Blaze._TemplateWith. It is the official
way to give a template data, after all, but it’s a little too weird to
make public. Use it in Blaze.renderWithData, even though it doesn’t
seem like it would make a difference.
Unify UI.render/renderWithData with Blaze.render, and add
toHTMLWithData. Publicly, they take a Template or a View.
The View must be unrendered, of course. If given a Template,
constructView will be called. Privately, they take any HTMLJS
extended to be allowed to contain Templates and Views, except
null or undefined, or a function returning extended HTMLJS.
The “data” argument may be a function or a not, as in UI.With
(and unlike the old public UI.renderWithData).
Make Blaze.toText private (Blaze._toText).
* `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)`
Destroy members of a DOMRange immediately on invalidation of the last render, not waiting for re-run. Provide DOMRange#destroyMembers.
Don’t call view.autorun from view.render() in builtins, and enforce it.
Remove dead code “onstop” from DOMRange.
Remove the spacebars-compiler -> spacebars and spacebars-compiler -> ui
dependencies. With those dependencies, ui cannot depend on
ui-dynamic-template, because ui-dynamic-template depends on templating,
whose build plugin depends on spacebars-compiler, who depends on
spacebars who depends on ui.
spacebars-compiler doesn't actually need to depend on ui or spacebars;
it only needs to depend on spacebars to add things to the `Spacebars`
namespace, which this commit does by factoring out the Spacebars export
into a separate `spacebars-common` package.
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)
The implementation is getting really, really ugly. Just want to get to correctness.
We now stop autoruns not just when started from `materialize` but also `toHTML`, `toText`, and `evaluate`, which is important for HTML attributes. Reactive regions inside attributes aren't individually autorun; the design is that their dependencies will cause the entire attribute updater to be invalidated and re-run. In other words, HTML.toText doesn't have internal re-runs but it does register dependencies on the current computation. In fact, however, the presence of emboxedValues means that there *are* autoruns that need to be stopped, even in toText and evaluate.
The hack where we define a `.materialized()` callback for the benefit of UI.With falls short, because toText et al. don't call it. The current workaround is yet worse hacks in htmljs (stopWithLater).
Finally, the fact that UI.If, UI.Unless, and Spacebars.include return reactive closures that close over emboxedValues is a problem when those same closures are reused in recalculating attributes. The intent was that recalculating attributes should tear down any boxes internal to the attribute calculation and start fresh, but when we reuse closures that close over boxes, we are reusing boxes, and if those boxes have been stopped we lose correctness. The ugly hack to get this to work for now is to have the boxes in If, Unless and include not be per reactive closure but per currentComputation, i.e. per autorun. Since toText et al. don't normally autorun reactive closures, we add an autorun so that they get their own Computation objects. This hack is supported by UI.namedEmboxValue and callReactiveFunction.
The good news is that the right answer is buried in here somewhere.
Unfortunately, using it always led to reactive functions
firing twice. Instead, we now use emboxValue in the two
cases we originally had Deps.isolateValue.
according to today's proposal (i.e. it's as if {{> content}} were invoked at the invocation site of the template that uses {{> content}}, as far as scopes are concerned).
Messy implementation with not enough comments. But there's a test.
All tests pass (except one which is a todo on shark).
If `{{> foo bar}}` is to desugar into `{{#with bar}}{{> foo}}{{/with}}`, there needs to be an explicit block in the generated code in which `self.lookup("foo")` binds the correct data context (`bar`). So we now generate a UI.With rather than trying to call it from Spacebars.include. This simplifies Spacebars.include, which is nice.
Define `lookupTemplate` because `self.lookup(.., {template: true})` pretty-prints bigly.
* Use isolateValue around `foo` in `{{> foo}}` as well as `{{#foo}}` (i.e. whether or not there's a content block)
* Make UI.With always embox its argument; this is achieved by moving embox/isolateValue from Spacebars into UI. As a side effected, all reactive closures now use isolateValue, so we avoid re-rendering in a few more cases.
* Avoid calling data argument of `{{#with someHelper}}` twice ever instead of once ever (when helper isn't invalidated)
So, in HTML, the following are equivalent, and both mean that a checkbox is checked, because the `checked` attribute is present:
- `<input type="checkbox" checked>`
- `<input type="checkbox" checked="">`
We can't mess with that. On the other hand, in Spacebars before this commit, the following would *also* result in the checkbox being checked, regardless of whether `foo` evaluates to null, undefined, false, or the empty string:
- `<input type="checkbox" checked={{foo}}>`
- `<input type="checkbox" checked="{{foo}}">`
With this commit, the checkbox will NOT be checked if `foo` evaluates to null, undefined, or false.
To achieve this:
- In HTMLjs, an attribute is considered absent if its value is "nully" after being fully evaluated (i.e. after expanding functions and components via HTML.evaluateDynamicAttributes / HTML.evaluate). A nully value is one consisting of null, undefined, an empty array, or an array of those things. `false` is not nully and renders as "false". An empty string is not nully, and will "prop open" an attribute that would otherwise collapse into absence.
- Spacebars.mustache converts null, undefined, and false to null. So if you use {{foo}} anywhere in a template and foo evaluates to "false", that gets to converted to a null in HTMLjs (which is ignored). (true is rendered as "true".)
- When parsing HTML, an attribute that consists of *no tokens* becomes an empty string in the HTMLjs, which props open the attribute (unlike null or an empty array). (Since comment tokens are stripped during tokenization, if there are only comments in an attribute value that counts as no tokens.)
- When helpers return SafeStrings, compare their underlying
strings.
- When helpers return objects (such as for dynamic attributes),
never isolate. The objects may have been mutated directly.
AttributeHandler ends up only affecting real changes.
