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
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 leave some of the dead code files in the “ui” package, but take them out of “package.js”. Some render tests now fail and maybe should be ported. Some test files are removed because they just tested the old code.
Some tests were actually passing because they used old code! Not anymore.
Create Blaze.toHTML(func) and Blaze.toText(func), like Blaze.render. Generally you should always build the HTMLjs from inside the func — and our tests should always be wrapping test content in a function literal, not passing around unrendered HTMLjs trees — but if you’re just using tags and Isolate, it doesn’t matter.
Some failing tests, which are hopefully mostly just tests of the modified code that need to be ported.
The main work was replacing the use of pseudo-attributes $special and $dynamic with the new HTML.Attrs(...) / array representation. Some functions were also rewritten to use Visitors (`toJS`, old `toHTML`/`toText`/`evaluateAttributes`, `replaceSpecials` in the compiler, but not `optimize` yet or `materialize`).
Create the "blaze-tools" package to hold toJS and other functions that are useful for template parsers/compilers that need to read or generate JS.
Both {{#foo}} and {{> foo}} are handled as follows:
- foo may be a template or a function returning a template
- if there are only keyword arguments, they are used to create a data context object (e.g. `x=1 y=2` becomes `{x:1, y:2}`)
- if there are any positional arguments, the arguments are treated as a nested helper call, meaning that the first one will be called on the rest (including keyword arguments) if it is a function
Rendering-wise, the template should only be re-rendered if foo is a function and it is invalidated to return a different value (though the "isolate" that would compare the new value to the old is not on this branch at the moment).
This change also makes the built-in block helpers (#if, #each, etc.) be functions (render macros) instead of components (though #each is still implemented with a component). This avoids data context issues with #if and #unless (the new calling convention isn't really designed to support making something like #if). It also should make generated code cleaner to call `UI.If` instead of including it as a component.
... unless you ask for it by name, in which case it can run on the client.
This means a smaller JS payload in production, without the HTML parser or Spacebars codegen.
Puts HTML.Tag, toHTML, and toJS in the "htmljs" package.
Introduces toText for textareas and attributes.
Changes dynamic attribute representation.
Instances of HTML.Tag, HTML.CharRef, etc. are now "instanceof".
Once this code seems to work, we'll move packages around further.
- "htmljs" is the runtime; can even take out "tocode.js"
- "html-tools" (new package) takes over for "html".
Then, port the tests.
