-
Notifications
You must be signed in to change notification settings - Fork 27.5k
Wrong cast to boolean #4277
Comments
@zakjan - Can you give the context where this is causing problems? |
I found this when used Quick solution was to double-not (!!) someVar. |
Should this be defaulted? On Tue, Oct 8, 2013 at 7:56 AM, Jan Žák notifications@github.com wrote:
|
Hmm, well if([]) { console.log('true'); }
> "true" |
This is where we are looking at: Line 863 in bed08c9
It explicitly handles the "[]" case. On Tue, Oct 8, 2013 at 9:52 AM, Pete Bacon Darwin
|
So maybe the fix could be to separate array length check just for arrays:
|
There is also another issue with functions: #5414 |
Make ngShow and ngHide follow javascript `truthy`/`falsy` logic and not the custom toBoolean logic Fixes angular#5414 angular#4277
Make ngShow and ngHide follow javascript `truthy`/`falsy` logic and not the custom toBoolean logic Fixes angular#5414 angular#4277 BREAKING CHANGE: The expressions * `<div ng-hide="[]">X</div>` * `<div ng-hide="'f'">X</div>` * `<div ng-hide="'[]'">X</div>` used to be evaluated to `false` and the elements were hidden. The same effect is present for `ng-show` and the elements are now visible
Make ngShow and ngHide follow javascript `truthy`/`falsy` logic and not the custom toBoolean logic Fixes angular#5414 angular#4277 BREAKING CHANGE: The expressions * `<div ng-hide="[]">X</div>` * `<div ng-hide="'f'">X</div>` * `<div ng-hide="'[]'">X</div>` used to be evaluated to `false` and the elements were hidden. The same effect is present for `ng-show` and the elements are now visible If you were previously doing `ng-show="exp"` where `$scope.exp = 'no' // (or 'n' or 'f')`, then instead write `ng-show="exp && exp !== 'no'` (or 'n' or 'f').
Make ngShow and ngHide follow javascript `truthy`/`falsy` logic and not the custom toBoolean logic Fixes angular#5414 angular#4277 angular#3969 BREAKING CHANGE: The expressions * `<div ng-hide="[]">X</div>` * `<div ng-hide="'f'">X</div>` * `<div ng-hide="'[]'">X</div>` used to be evaluated to `false` and the elements were hidden. The same effect is present for `ng-show` and the elements are now visible; and with `ng-if` and the elements are now removed If you were previously doing `ng-show="exp"` where `$scope.exp = 'no' // (or 'n' or 'f')`, then instead write `ng-show="exp && exp !== 'no'` (or 'n' or 'f').
Make ngIf, ngShow and ngHide follow javascript `truthy`/`falsy` logic and not the custom toBoolean logic Fixes angular#5414 angular#4277 angular#3969 BREAKING CHANGE: The expressions * `<div ng-hide="[]">X</div>` * `<div ng-hide="'f'">X</div>` * `<div ng-hide="'[]'">X</div>` used to be evaluated to `false` and the elements were hidden. The same effect is present for `ng-show` and the elements are now visible; and with `ng-if` and the elements are now removed If you were previously doing `ng-show="exp"` where `$scope.exp = 'no' // (or 'n' or 'f')`, then instead write `ng-show="exp && exp !== 'no'` (or 'n' or 'f').
Make ngIf, ngShow and ngHide follow javascript `truthy`/`falsy` logic and not the custom toBoolean logic Fixes angular#5414 angular#4277 angular#3969 BREAKING CHANGE: The expressions * `<div ng-hide="[]">X</div>` * `<div ng-hide="'f'">X</div>` * `<div ng-hide="'[]'">X</div>` used to be evaluated to `false` and the elements were hidden. The same effect is present for `ng-show` and the elements are now visible; and with `ng-if` and the elements are now removed If you were previously doing `ng-show="exp"` where `$scope.exp = 'no' // (or 'n' or 'f')`, then instead write `ng-show="exp && exp !== 'no'` (or 'n' or 'f').
So far Angular have used the toBoolean function to decide if the parsed value is truthy. The function made more values falsy than regular JavaScript would, e.g. strings 'f' and 'no' were both treated as falsy. This creates suble bugs when backend sends a non-empty string with one of these values and something suddenly hides in the application BREAKING CHANGE: values 'f', '0', 'false', 'no', 'n', '[]' are no longer treated as falsy; only JavaScript falsy values are treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, o and "". Fixes angular#3969 Fixes angular#4277
So far Angular have used the toBoolean function to decide if the parsed value is truthy. The function made more values falsy than regular JavaScript would, e.g. strings 'f' and 'no' were both treated as falsy. This creates suble bugs when backend sends a non-empty string with one of these values and something suddenly hides in the application BREAKING CHANGE: values 'f', '0', 'false', 'no', 'n', '[]' are no longer treated as falsy. Only JavaScript falsy values are now treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, o and "". Fixes angular#3969 Fixes angular#4277
So far Angular have used the toBoolean function to decide if the parsed value is truthy. The function made more values falsy than regular JavaScript would, e.g. strings 'f' and 'no' were both treated as falsy. This creates suble bugs when backend sends a non-empty string with one of these values and something suddenly hides in the application BREAKING CHANGE: values 'f', '0', 'false', 'no', 'n', '[]' are no longer treated as falsy. Only JavaScript falsy values are now treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, o and "". Fixes angular#3969 Fixes angular#4277
So far Angular have used the toBoolean function to decide if the parsed value is truthy. The function made more values falsy than regular JavaScript would, e.g. strings 'f' and 'no' were both treated as falsy. This creates suble bugs when backend sends a non-empty string with one of these values and something suddenly hides in the application BREAKING CHANGE: values 'f', '0', 'false', 'no', 'n', '[]' are no longer treated as falsy. Only JavaScript falsy values are now treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, 0 and "". Fixes angular#3969 Fixes angular#4277
So far Angular have used the toBoolean function to decide if the parsed value is truthy. The function made more values falsy than regular JavaScript would, e.g. strings 'f' and 'no' were both treated as falsy. This creates suble bugs when backend sends a non-empty string with one of these values and something suddenly hides in the application Thanks to lgalfaso for test ideas. BREAKING CHANGE: values 'f', '0', 'false', 'no', 'n', '[]' are no longer treated as falsy. Only JavaScript falsy values are now treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, 0 and "". Fixes angular#3969 Fixes angular#4277
So far Angular have used the toBoolean function to decide if the parsed value is truthy. The function made more values falsy than regular JavaScript would, e.g. strings 'f' and 'no' were both treated as falsy. This creates suble bugs when backend sends a non-empty string with one of these values and something suddenly hides in the application Thanks to lgalfaso for test ideas. BREAKING CHANGE: values 'f', '0', 'false', 'no', 'n', '[]' are no longer treated as falsy. Only JavaScript falsy values are now treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, 0 and "". Fixes angular#3969 Fixes angular#4277
So far Angular have used the toBoolean function to decide if the parsed value is truthy. The function made more values falsy than regular JavaScript would, e.g. strings 'f' and 'no' were both treated as falsy. This creates suble bugs when backend sends a non-empty string with one of these values and something suddenly hides in the application Thanks to lgalfaso for test ideas. BREAKING CHANGE: values 'f', '0', 'false', 'no', 'n', '[]' are no longer treated as falsy. Only JavaScript falsy values are now treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, 0 and "". Fixes angular#3969 Fixes angular#4277
So far Angular have used the toBoolean function to decide if the parsed value is truthy. The function made more values falsy than regular JavaScript would, e.g. strings 'f' and 'no' were both treated as falsy. This creates suble bugs when backend sends a non-empty string with one of these values and something suddenly hides in the application Thanks to lgalfaso for test ideas. BREAKING CHANGE: values 'f', '0', 'false', 'no', 'n', '[]' are no longer treated as falsy. Only JavaScript falsy values are now treated as falsy by the expression parser; there are six of them: false, null, undefined, NaN, 0 and "". Closes angular#3969 Closes angular#4277 Closes angular#7960
toBoolean(window) === false
because of that
toBoolean(value)
function checksvalue.length
property, which means forwindow
the count of (i)frames - usually 0.The text was updated successfully, but these errors were encountered: