feat(ngRepeat): provide support for aliasing filtered repeater results as a scope member

[matsko]

ngRepeat can now alias the snapshot of the list of items evaluated after all filters have
been applied as a property on the scope. Prior to this fix, when a filter is applied on a
repeater, there is no way to trigger an event when the repeater renders zero results.

Closes #5919

[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 (#8046)

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 am trying to understand why this feature is needed. What is wrong with ng-repeat="item in (result = items | filter:x)"
?

[matsko]

I wasn't aware of that trick, but I don't know if that would be considered stable. I'll send out an email to ask about this.

[kevinjamesus86]

For what it's worth I've been using an 'as' filter to accomplish this:

angular.module('somemodule').filter('as', function($parse) {
  return function(value, path) {
    return $parse(path).assign(this, value);
  };
});

I've found this to be useful because I can get a snapshot of the data anywhere along the filter chain:

ng-repeat="item in items | filter:x | as:'result'"
ng-repeat="item in items | orderBy:sort | as:'items.sorted' | filter:x | as:'items.result'"

not the worlds best example but you get the idea.

[matsko]

@lgalfaso I just talked with @IgorMinar and the assignment operator will likely be removed from Angular down the road.

[IgorMinar]

lgtm

@kevinjamesus86 suggestion is interesting but the syntax is not developer friendly

[Narretz]

Just an idea: if this was a function of the filter instead of ng-repeat, you could handle sub-results like @kevinjamesus86 showed, and ng-repeat wouldn't be so bloated

[lgalfaso]

Ah, was not aware that the assignment operator was going to be removed. In that case LGTM

[caitp]

The assignment operator is not going to be removed, that would be complete nonsense. At this point it just doesn't make any sense to do that in 1.x

[IgorMinar]

@caitp not any time soon. But I did tell @matsko that I'd like it to be gone some time in the future. Likely in the 2.x timeframe. We should be doing imperative model mutation from controllers/js and not from templates.

[IgorMinar]

@Narretz interesting idea, but with the exception of ngRepeat in what other scenarios would this be useful?