On Blaze, we copied functionality we had on Spark: Don't update
form controls (INPUT, TEXTAREA) if they are focused and their underlying
value reactively updates. This was never meant to be the eventual
solution -- we'd eventually have a way to define strategies for two-way
data binding. Maybe you'd be able to define a callback that notifies
the app when a change happens to a field that hasn't been saved yet.
Moreover, not only is the feature incomplete, but with Blaze it works
much more poorly than in Spark. Due to fine-grained updates, users
his this more frequently and don't seem to like the behavior
(in Spark you would only hit this behavior if you set up your
preserve rules exactly right, which many users did not do).
So, we're just ripping out this functionality. Now if a field gets
edited by some other user while you're focused it will just lose its
value. Focus will remain.
Fixes#1965
They used to run the query twice: once for the actual result and once to
set up the observe. Now it shares the work between the observe and the
actual query.
This required me to inline the _depend helper, but I actually think this
made what's going on more direct and clear.
Drop the _allow_unordered hack. I'm not convinced that it was ever truly
valid; the observe code really doesn't support unordered observes with
skip and limit, and I could not remember what it was about count's use
that made it hypothetically safe. Easier to just remove the hack (until
we maybe eventually actually fix#1643)
Stop using Deps.Dependency in an unidiomatic way; just use
Deps.currentComputation directly.
Our cursor interface has no nextObject method, so there's no point in
having a rewind method. Its major effect is ensuring that
fetch/forEach/map return no documents if you've already called one of
them once. It's not clear why this is actually useful to anybody.
rewind is kept around as a no-op; if we later implement nextObject, we
can make rewind do something, but we still presumably would auto-rewind
before fetch/forEach/map.
In minimongo, remove the db_objects cache inside each cursor. The only
actual use of this cache was that if you called count multiple times, it
would return the same number without re-running the query, and you could
share the query work between N calls to count and one call to
fetch/forEach/map (but only one call! future calls would return
nothing!) While there's a minor performance hit from getting rid of
this cache, it should also use a little less memory, and enable use
cases like
{{#with someCursor}}
{{#if count}}
{{#each this}}
...
{{/each}}
{{/if}}
{{/with}}
which didn't work before because even the deps invalidation didn't
rewind the cursor.
Also, as a minor optimization, skip an EJSON.clone if there's a
projection, because projection functions are guaranteed to clone.
Fixes#2114
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`).
Instead of `callWithNoYieldsAllowed` which calls a function
within (introducing a new stack frame that doesn't absolutely
nothing on the client), we now use `withNoYieldsAllowed` that
returns a new function that then gets called.
Since Deps is used all over the place, and in particular
in Blaze, this makes it much easier to look at the stack
trace when stopping in a debugger (for example, when a helper
gets re-executed).
Motivated by the Blaze manual.
There were two separate issues here:
- npm-shrinkwrap.json wasn't actually being used as part of the
watchset/buildinfo, so changes to it might not cause the package to
be considered for rebuilding
- meteor-npm only compared top-level changes when deciding whether to
update, not all changes
Fixes#1648
The main changes are:
* The `isSafe` check happens before _endOfLoginResponse is called. If
_endOfLoginResponse gets a credential token/secret, then the values
are safe to include in HTML.
* _endOfLoginResponse gets a little more information about the request
(like the query string, and a string or Error describing any error
that occurred).
* We preserve the <=0.8.1.3 behavior where you have to pass ?close in
the query parameter to get the popup to be closed at the end of the
OAuth flow.
This code has never worked without some fairly serious client-side
surgery, and it now especially doesn't work because it doesn't
communicate the credentialSecret back to the app. Rather than leave an
untested, unQA-ed code path in core, apps that are using the ?redirect
flow can just override `OAuth._endOfLoginResponse` to do the redirect
themselves.
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.
