This started causing test failures in deployed tests while testing the 0.4.1
release candidate; we think this may be related to bumping the mongodb node
driver version. (Maybe the change to this.poolSize in
f81870f7da
?)
Meteor will use jQuery for selector matching if it's present on the
client (which at the moment is always), but it now will use bare
querySelectorAll on modern browsers and IE 8+ if there is no jQuery.
There is no other dependence on jQuery in Meteor.
For now, the old names still work as well.
This includes:
- Meteor.isServer/isClient
- this.isSimulation in methods
- Context.onInvalidate
- Meteor.status().retryCount/retryTime
Remove old backwards-compatibility "Sky" alias for "Meteor".
Update all examples in the docs to use camelCase.
Delete unused docs/client/projects.html file.
To test whether an element in the event bubbling chain matches a
selector, we now modify the selector to include an ID for the
element in question (which we assign if it doesn't have one),
so we search for one node rather than listing and checking all
nodes that match the selector! This makes a huge speed difference in
the jsparse demo, which binds a global handler over a big DOM tree.
The new domutils are matchesSelector(element, contextNode, selector)
and matchesSelectorClipped(element, contextNode, selector, clipStart,
clipEnd).
Note: Eventually make the args more like this W3C working draft:
http://www.w3.org/TR/selectors-api2/#matches
This isn't the kind of dynamic var that should
persist into timer callbacks, it should just be
on the stack. Also cuts dependence of spark
on dynamics.
This is a carefully considered change motivated by Tinytest, which
fires timers from a method and then waits for them before returning.
Because the timer callbacks didn't have a WriteFence, we had a race
condition a while back where the test client would quiesce before all
the results came in, which I fixed by giving Tinytest its own timer
functions that kept the environment, including the WriteFence.
I want to tear these special timer functions out now, since they are
necessary (before this commit) for very obscure reasons. The race
condition is hard to reproduce and is affected by Mongo latency, the
order of the unit tests, etc. (I reproduced it semi-stably to test
this commit, and it was tricky.)
The change is to give timer callbacks the WriteFence and allow them
to add writes before or after the fence fires. Writes that they get
in before the fence is armed are included in the fence, and writes
made after the fence fires still succeed (the fence is "retired" and
doesn't complain that it has already fired). In practice, this means
that methods that care about the writes happening as part of the
method, like Tinytest's run method, can wait for them, and methods
that don't care to wait will just return and let the writes trickle
down the pipe later (as they could before).
In a discussion with Geoff a few weeks ago, he said fences in general
should still complain about late writes unless they are put in a
special mode, so there is now a retire() method.
We want to _diffQuery when we've just quiesced after a method completion or a
subscription becomes ready, but if we're in the steady state and just got a
single subscription update from the server, we can run observers directly (which
should be faster).
Previously, if the callback yields (eg, if it does a DB query), the next
iteration of the callback could run, or the forEach could finish entirely,
because the future we waited on only checked to ensure that the callback was
*started* on all documents, not *finished*.
Fixes#321. Thanks to Scott Anderson for bug report with minimal reproduction
case.
In the browser, `deepcopy` seemed to be successfully cloning dates, but server-side this was not the case. Commit b21da0f274 introduced a `deepcopy` to the process of pulling data out of mongo, so this is needed. Fixes#295
Consensus is that "render" is too confusing a name for what's obviously a callback (after the template is rendered). We prefer past tense rather than oncreate, onrender, ondestroy.
Landmarks nested inside a DOM node in a re-rendered range weren't
being preserved, because the selector was being run on the old
DOM and new DOM with the context node from the old DOM. Fix is to
only use the preservation root 'context' option for the case where
the landmark is above the re-rendered region.
