When a range is removed, if the component instance has a destroyed callback
defined, updateTemplateInstance is called and the destroyed callback is called
in the context of the updated templateInstance. updateTemplateInstance calls
getComonentData() which can create a reactive dependency. This doesn't seem
necessary since we're removing the range.
The problem surfaced in iron-router in combination with using the {{#each
helper. The each helper is currently the only builtin that adds a destroyed
callback. If a previous layout used {{#each and a new layout rendered, the
previous range would be removed in the new computation. Then, if we updated the
data context, the dep would change and the entire new layout would be rendered
again :-(.
cc @tmeasday.
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
Apparently `../this` used to work as a synonym for `..` in Handlebars, but in Spacebars it actually would look for a property named `this`, which caused confusing breaking changes in apps.
Can't use what's effectively an "eval" and still be safe for restrictive Content Security Policies. Hopefully we get a better way to make classes print nicely in the dev console in the future.
- Start shrinking html.js down to the 150-line file it can be
- Move "proper case" logic to the template compiler; the tagName of an HTMLjs tag is now in proper case. This is both for better performance and reduced size and complexity of runtime code (i.e. blaze.js).
- Start moving html-tools to the HTMLTools namespace
This matches what the SockJS server uses; now we only need to understand
and fix bugs in the implementation of one websocket npm module.
Some notes:
- I actually trust that it's possible to close a connection before it
successfully connects, which allows me to simplify the code a
lot (since there shouldn't be multiple connections active per
ClientStream). I put in some assertions to make sure this is the
case, though. (Note that this module also has a simpler model,
where there's a single object representing the client connection,
not a "client" object that spawns "connections".)
- We now print connect errors as well as post-connect errors. (This
required adding a flag to keep tests quiet since it makes an
expected-to-fail-to-connect connection.) We need a better approach
to stream error handling, though.
- We used to have a test to make sure that a certain not-user-visible
callback is called within a Fiber; structuring the code such that
this test is still possible would lead to the code being less
consistent and harder to read, so I dropped the test.
- Fix a few bugs where we weren't using Meteor.setTimeout.
