Update expression.ngdoc

[twwwt]

Please, update the section on one-time bindings by another example showing how the feature can be used with filter (chains). I was very surprised - positively - when I discovered that feature today and wished I could have read something about it before, which would have saved me some time.

[mary-poppins]

I'm sorry, but I wasn't able to verify your Contributor License Agreement (CLA) signature. CLA signature is required for any code contributions to AngularJS.

Please sign our CLA and ensure that the CLA signature email address and the email address in this PR's commits match.

If you signed the CLA as a corporation, please let us know the company's name.

Thanks a bunch!

PS: If you signed the CLA in the past then most likely the email addresses don't match. Please sign the CLA again or update the email address in the commit of this PR.
PS2: If you are a Googler, please sign the CLA as well to simplify the CLA verification process.

[rodyhaddad]

This isn't quite right. ::(text | someFilter) is actually the same as ::text | someFilter.
We consider an expression to be one-time binded when the first two non-whitespace characters are "::", regardless of what follows.

The first half of the added diff is correct though and worth elaborating in the doc (the avoid re-filtering part).

[twwwt]

Well, at least for the tests that I did using 1.3.0-beta18, the two versions behaved differently in the way I have described it. More precisely, the two expressions that I have tested were {{ ::'myString' | myFilter }} and {{ ::('myString' | myFilter) }} where myFilter is a filter that we have developed, which is closed source and therefore I cannot release its source here. To say little more about the filter, it's quasi an asynchronous filter that depends on a service that in turn needs to fetch a resource asynchronously first in order to be able to work meaningfully. The filter returns undefined unless it is ready and irrespective of the input. So, while {{ ::'myString' | myFilter }} got stable immediately (seemingly because of the constant string expression) and in our case always before the filter was ready (i.e., while it was still returning undefined), the other version {{ ::('myString' | myFilter) }} got stable always after the filter was ready.

I haven't further analyzed Angular's source code, but it seems that this is a feature implied by the code.

[rodyhaddad]

Being familiar with Angular's source code, I can assure you that both are evaluated the same by the expressions parser. If they're behaving differently in your app, it's probably something unrelated that's causing that.

Here's a plnkr trying to replicate what you describe, a constant value passed to an asynchronous filter with one-time binding in the expression: http://plnkr.co/edit/mHmuSTu0KR95YZHzZ5Lf?p=preview

If I missed anything, please let me know. If you can link to a plnkr that reproduces your scenario, that would be great.

---

Again, I believe the first part of the doc changes are worth adding, and maybe even elaborating on

[mary-poppins]

CLA signature verified! Thank you!

Someone from the team will now triage your PR and it will be processed based on the determined priority (doc updates and fixes with tests are prioritized over other changes).

[caitp]

@rodyhaddad is correct --- see

angular.js/src/ng/parse.js

Lines 1047 to 1050 in c90ad96

	if (exp.charAt(0) === ':' && exp.charAt(1) === ':') {
	oneTime = true;
	exp = exp.substring(2);
	}

@twwwt were you planning on updating this?