toBoolean returns false if "f" string is passed as argument. That prevents ng-show to evaluate to true when filtering text is "f" string

[ttsvetko]

I'm implementing a custom search field that consists of an text input element and a close icon that should appears when there is an entered text into the field. For that particular case i'm using ng-show to display the close icon.

Please see the example:
http://jsbin.com/oquhor/2/edit

Any string except "f", "false", "0", "n" and "no", shows the div element. But if i enter some of the mentioned strings the div element disapears. In other words when i start to type the word "false", when i type "f" letter the div will not be displayed, on typing "a" the div appears, and when i type the whole word "false" the div disappears again.

I took a look at the ng-show directive - it calls toBoolean function that returns false if the passed string is "f", "false", "n", "no" or "0". It is correct to accept "no" string for falsy value, but it is not correct from the javascript perspective where empty sting is evaluated to false, but any non-empty string is evaluated to "true".

I checked and if i use ng-hide instead of ng-show, everything works just fine. But it is supposed to get the same results in the both cases.

[latentflip]

The reason that ng-hide is working "differently" is that you are doing <div ng-hide="!search">This works correct in all cases.</div>. The ! operator will cast your search variable to true/false in javascript, before the directive takes over and does it's "n" checks etc, and since only an empty string is falsy, this will work.

So the question is should this be fixed in angular, or is it just an edge case where your app needs to deal with it?

I would argue the latter, and that this could probably be closed. Even if we tightened it up to not count "f" or "no" as falsy, your implementation would have troubles if someone searched for "false". And going all the way to saying that only true and false are allowed in ng-show will probably break more implementations than it will help.

One solution for you would be to create a new truthy variable using a $watch, like this: http://jsbin.com/oquhor/3/edit

How's that? If you're happy can we close this issue: trying to get that big 400 count down 😄

Thanks!

[ttsvetko]

Seems fine for me :) using a $watch can help and it is better to spend time fixing more serious issues than this one :) Lets close it.

[latentflip]

Thanks! 👍

On 30 January 2013 08:40, Tsvetan Tsvetkov notifications@github.com wrote:

Seems fine for me :) using a $watch can help and it is better to spend
time fixing more serious issues than this one :) Lets close it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1229#issuecomment-12879459.

[peterldowns]

The documentation includes a note on this (treating certain JS-truthy values as falsy), but I'm curious: why deviate from standard JS behavior here?

[caitp]

@peterldowns bdfc9c0

[peterldowns]

@caitp I just saw the fix, I was curious for the historic justification :)