Expressions don't understand Infinity

[Alexsey]

Infinity in expressions is not treating as Infinity number, but as variable
Plunker
So it even can be override
Plunker

[btford]

@IgorMinar @caitp do we want to expose Infinity in Angular expressions?

[caitp]

I'm not sure what the use case is, but I don't think it's that bad to add it. On the other hand, the parser doesn't understand NaN either, so maybe we don't need it?

[caitp]

It would be like 2 lines to add support for both I think, since they're keywords that could be added as constant getters

[Alexsey]

@caitp Well, I met this when checking devision on zero edge case. Also I prefer to use Infinity instead of something like 10000000 for things that must be the biggest of their kind.

Generally the use of Infinity is a question of taste, and always you could go without it. But it is really confusing when definitely correct code fails.

[btford]

Also I prefer to use Infinity instead of something like 10000000

I think better would be to expose a function on scope, so it becomes a question of {{ isLessThanInfinity(someNum) }} versus {{ someNum < Infinity }}

definitely correct code

Reminder that Angular expressions are a subset of JavaScript.

[caitp]

Or even just Number.isFinite(value) which should work even in the expression language (I mean, you aren't going to have a value which is greater than Infinity or less than -Infinity anyways)

[Alexsey]

Number.isFinite(value) is good. Or even lodash's _.isFinit(value). It suit as well as {{someNum < Infinity}}. I know this now, but if someone else meet same situation he could stuck same way. Because they are nearly equally good.

This should be in the docs, in Angular Expressions vs. JavaScript Expressions section. But does absence of Infinity and NaN is so important to make documentation a little bit harder and explain why they should not be in expressions?

[caitp]

I don't have a strong opinion on this, I mean it would be pretty trivial to add support for Infinity/NaN as constant getters, or we could just document the difference with JS. It's all good

[caitp]

i think we have to draw the line at supporting the void operator though :>

[btford]

aw, was really hoping for comma operator and void operator support so i can do: ng-click="doFoo(), void 0"

[Alexsey]

well... if there where on void in ECMAScript and someone propose to add such in Angular that would definitely fail :)

But it's not about adding void to Angular, it's about removing unnecessary inconsistent with parent spec. So I think void should be added to if there is no reasons for not to adding it.

IMHO comma is a separate topic because its usage considers as 'bad practice' except of cases that may not appear in expressions. As for me user should decide to use it or not, but I'm not as deep in understanding philosophy of Angular to argue about would it supplement with other expressions restrictions or not.

[IgorMinar]

Gut feeling: -1

Keep templates and expressions simple.

On Wed, Oct 8, 2014, 3:26 PM Alexsey [email protected] wrote:

well... if there where on void in ECMAScript and someone propose to add
such in Angular that would definitely fail :)

But it's not about adding void to Angular, it's about removing
unnecessary inconsistent with parent spec. So I think void should be
added to, if there is no reasons for not to adding it.

IMHO comma is a separate topic because its usage considers as 'bad
practice' except of cases that may not appear in expressions. As for me
user should decide to use it or not, but I'm not as deep in understanding
philosophy of Angular to argue about should it be in expressions or not.

—
Reply to this email directly or view it on GitHub
#9492 (comment).

[Alexsey]

Should I close this, or you would like to add something else?

[jjlorenzo]

ng-if="reactor.operationTime === Infinity"

IMHO this is a simple expression, at least more than the hack that works for me:

ng-if="reactor.operationTime === 1/0"

[AlexanderLeonov]

Will do some necroposting here. :)
Another use case for that would be like this:

<select ui-select2="{ minimumResultsForSearch: Infinity }">

It doesn't make sense for me to add something onto scope for select2 configuration which is that simple - all I want is just hide search box, that's it. Otherwise I'd have to create controller or directive which would place this config on the scope for me, or to make some existing entity to do it. Then if we consider 3-4 such select2's on the page, and 3-4 is not even close to "many"... No, that's definitely overkill. But I'm using angular 1.5.0 and it still doesn't work. :(

[jjlorenzo]

I don't know if works for you, but in my case I use a hack: 1/0 <select ui-select2="{ minimumResultsForSearch: 1/0 }">

[AlexanderLeonov]

@jjlorenzo Thanks for helping me, I've seen your earlier comment here. It can work of course, but I'm not fond of any kind of hacks if it could be done in a proper way. Also if tomorrow they'll change 1/0 behavior to throw an exception or return zero or whatever else then this code will break. I'm not excited of dealing with such things, so still +1 for implementing explicit support for Infinite

[jjlorenzo]

I'm totally agree with you, but comming from django world where the template language are very limited, this design decision is not new for me. ​