Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Update expression.ngdoc #8776

Closed
wants to merge 1 commit into from
Closed

Update expression.ngdoc #8776

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions docs/content/guide/expression.ngdoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -321,3 +321,13 @@ When using a directive that takes an expression
</ul>
```

When using a filter (chain) to avoid filtering expression values over and over
again on each digest cycle.

```html
<div>{{::(text | someFilter)}}</div>
```

Observe that `::(text | someFilter)` is not the same as `::text | someFilter`. The
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

former is unstable as long as the last filter returns undefined while the latter
is unstable as long as `text` is undefined.