Add support to mix in delayed delta changes

Add support to mix in delayed delta changes

Due to a race condition the unit details view would sometimes not update
as per the databinding because there were some deltas which had not yet 
been applied. This adds the functionality to mix these deltas in or
filter by them as was the previous functionality.

https://code.launchpad.net/~hatch/juju-gui/unit-breakout-1253114/+merge/197619

(do not edit description out of merge proposal)

[jeff.pihach, 2013-12-03 22:49:16]

Please take a look.

[gary.poster, 2013-12-04 01:52:31]

Hey Jeff.  Thank you for tackling this tricky problem.

I think your attention on this area has indicated that resetDOMToModel needs
some changes to deltaFromChange, because it should also reset dependents.

However, I don't think that your change to _modelDOMHandler is right.  It's too
big.  See my comments below.  I could be wrong, but I'd like to talk this
through with you tomorrow.

Thanks,

Gary

https://codereview.appspot.com/36850043/diff/1/app/views/databinding.js
File app/views/databinding.js (right):

https://codereview.appspot.com/36850043/diff/1/app/views/databinding.js#newco...
app/views/databinding.js:159: changed value list or filter to use only those
bindings. Default false.
I want to remove this new parameter.  See below.

https://codereview.appspot.com/36850043/diff/1/app/views/databinding.js#newco...
app/views/databinding.js:176: if (modelChangeKeys !== undefined &&
modelChangeKeys.length !== 0) {
I suggest we change the rest of this code as follows.

var filteredBindings = bindings;
if (modelChangeKeys !== undefined && modelChangeKeys.length !== 0) {
  // In this branch of the the conditional, we only have a specific set
  // of keys that have changed, so we want to limit the resulting
  // bindings appropriately.
  var filteredBindings = bindings.filter(function(binding) {
    // Change events don't honor nested key paths. This means
    // we may update bindings that impact multiple DOM nodes
    // (our granularity is too low).
    return (modelChangeKeys.indexOf(binding.name.split('.')[0]) > -1);
  });
}

// Add dependents.
...

https://codereview.appspot.com/36850043/diff/1/app/views/databinding.js#newco...
app/views/databinding.js:216: } else {
This branch would disappear.  Now, if you don't specify modelChangeKeys, you get
bindings *plus* dependent bindings.

https://codereview.appspot.com/36850043/diff/1/app/views/databinding.js#newco...
app/views/databinding.js:718: delta = deltaFromChange.call(this);
Shouldn't this include dependents?  If so, the deltaFromChange function could be
a lot prettier.  See discussion above.

https://codereview.appspot.com/36850043/diff/1/app/views/databinding.js#newco...
app/views/databinding.js:872: delta = deltaFromChange.call(this,
this._unappliedChanges, true);
I'm proposing that this could be spelled 

delta = deltaFromChange.call(this);

However, why do we want to ignore the fact that we know what the unapplied
changes are?  It seems wrong.  Could you explain?  I have a feeling that this is
too blunt of a hammer.

If it *is* the right approach, we need a very good explanation in the
comments...*and* we should remove all references to _unappliedChanges, because
it is never used in your code.

[jeff.pihach, 2013-12-04 17:06:12]

Please take a look.

[gary.poster, 2013-12-04 17:14:47]

LGTM, thank you!

[jeff.pihach, 2013-12-04 17:23:16]

*** Submitted:

Add support to mix in delayed delta changes

Due to a race condition the unit details view would sometimes not update
as per the databinding because there were some deltas which had not yet 
been applied. This adds the functionality to mix these deltas in or
filter by them as was the previous functionality.

R=gary.poster
CC=
https://codereview.appspot.com/36850043