perf(*): more performant interpolation and lazy one-time binding

[rodyhaddad]

This PR implements a different approach to one-time binding, which also gives us a performant improvement for $interpolate by about 33%.

Here's a benchmark app using the current snapshot: plunkr
Here's the same benchmark with this PR: plunkr

Look at the difference between the two baseline interpolation. It goes from 30-35ms to 20-25ms.
This gets us closer the the baseline binding, which is about 15-20ms.
The other 3 benchmarks in the benchmark app remain unchanged.

What's behind this change:

Expressions can say how they want to be watched

This allows the following:

• Given interFn = $interpolate('{{a}}{{b}}'), interFn can say that it wants to be watched by: watching each expression individually (i.e. scope.$watchGroup(['a', 'b'])
• Given parseFn = $parse('1 + 1'), parseFn can say that it wants to be watched by: getting evaluated on the next $digest, and then unregistering itself since its constant anyway
• Given parseFn = $parse('::foo'), parseFn can say that it wants to be watched by: getting evaluated on the $digest as usual, and unregistering itself when its value is no longer undefined (a.k.a. bind-once)

InterceptionFn

There are cases where the last scenario doesn't work out as we'd like.
If we're watching a function that calls parseFn inside it, we lose the benefits mentioned above. That's because parseFn isn't aware that it's being watched (indirectly). So I created an interceptorFn in $parse that goes around this issue. Interceptors work as filters and you can easily see their application in ngBind.js or sce.js

---

I could go into more details, but you should check the code.
The first commit just reverts the current implementation of bind-once, so checking the second commit on it's own can make reviewing easier
Suggested order of review:

• rootScope.js
• interpolate.js
• parse.js
• The rest

[mary-poppins]

Thanks for the PR! Please check the items below to help us merge this faster. See the contributing docs for more information.

• Uses the issue template (#7700)

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[lgalfaso]

I would like to know where is that we are spending this extra cycles in the current implementation (without thinking on one-time binding). Trying to tackle both things at the same time makes it a lot harder to understand the problem and what this patch is trying to solve

[caitp]

if (parsedExpression.constant) parsedExpression.$$beWatched = constantWatch;
else if (oneTime) parsedExpression.$$beWatched = oneTimeWatch;

saves a comparison for the majority of cases

[caitp]

#8029 is fixed by this (if the build weren't broken, I mean).

Here's a bonus test case you can add to prevent that from being broken similarly in the future,

it('should NOT insert null option when blurred without selection with bind-once options', function() {
  scope.values = [{name: 'A'}, {name: 'B'}, {name: 'C'}];
  scope.selected = scope.values[0];
  createSelect({
    'ng-model': 'selected',
    'ng-options': 'value.name for value in ::values'
  });

  browserTrigger(element, 'blur');

  expect(element.children('option').length).toBe(3);
});

I guess the real test is more like this:

it('should use exact same values as values in scope with one-time bindings', function() {
  scope.values = [{name: 'A'}, {name: 'B'}];
  scope.selected = scope.values[0];
  createSelect({
    'ng-model': 'selected',
    'ng-options': 'value.name for value in ::values'
  });

  browserTrigger(element.find('option').eq(1));

  expect(scope.selected).toBe(scope.values[1]);
});

[IgorMinar]

just fyi that we prefer multiple vars in new code as that makes refactoring easier.

[IgorMinar]

"wgExpression" -> "watchGroupSubAction" ?

[Narretz]

Will this make it to the next release? If not, can we add the support for one-time binding of object literals (ng-class etc.) to the current implementation? I know it was in this PR, but I can't seem to find it atm.

[rodyhaddad]

@Narretz It was in a commit on my fork (rodyhaddad@c9ee324), and it was for #7663

[Narretz]

@rodyhaddad So once this is merged, the other change can be merged, too, right?