One-time binding doesn't work with filters

[cnshenj]

This works fine:

<div ng-bind="test.value | number"></div>

This works fine too:

<div ng-bind="::test.value"></div>

But this renders an empty div:

<div ng-bind="::test.value | number"></div>

[jeffbcross]

I created a plnkr and can't reproduce the issue in Chrome.

What version of Angular are you using, and in what browser are you seeing this issue?

http://plnkr.co/edit/1kIw8FaQJQZLcvCArXS4?p=preview

[cnshenj]

plnkr is so slow.

To repro:

1. Don't use ng-init, use ng-controller to assign the initial value: scope.test.value = undefined
2. Assign the actual value outside of Angular and call $apply (e.g. do this when a button is clicked)

Without "::" the new value is properly processed by filter and bound to the element. Then add "::" to see the element become empty.

[caitp]

I'm pretty sure the reason for this is that the filter is not returning undefined when the input value is undefined. That seems like the expected behaviour.

[caitp]

Yep, numberFilter returns the empty string if the input value is null or undefined.

This doesn't really strike me as wrong per se, you could just write another filter that uses the number filter if the value is not undefined (the way one-time binding works is, it stops watching as soon as the value becomes something that is not undefined. But even if it worked the way the original prototype worked, where it watches until the value stabilizes, this would still not do what you want. Sorry!)

[cnshenj]

I believe Caitlin is right. However, rewriting all built-in filters to support one-time binding probably should be done in Angular, rather than be done by all users repeatedly.
If "a.b | filter" works, it's very natural to just add one-time binding attribute by prepending "::". Having two sets of almost identical filters to support non-one-time and one-time binding doesn't sound right.

[caitp]

There's no way for a filter to know if you are expecting the value to be one-time bound or not, unless we add a new flag or something, which is not likely to happen, and even if it did, you'd still have to tell the filter that's what was going on.

We could change the parser to not evaluate filters if the value is one-time bound and still undefined, but until we do that, this is really working as expected. That might be a complicated change :(

[cnshenj]

Since Angular expressions are forgiving, wouldn't it make sense for filters to return undefined instead of empty string when input is undefined or null? Thus, filters will work for both persistent and one-time bindings.

[IgorMinar]

@caitp why not change the number filter to return undefined as @cnshenj suggested?