Short Answer
For ECMAScript-5 Users:
#1
if(x !== x) {
console.info('x is NaN.');
}
else {
console.info('x is NOT a NaN.');
}
For people using ECMAScript-6:
#2
Number.isNaN(x);
And For consistency purpose across ECMAScript 5 & 6 both, you can also use this polyfill for Number.isNan
#3
//Polyfill from MDN
Number.isNaN = Number.isNaN || function(value) {
return typeof value === "number" && isNaN(value);
}
// Or
Number.isNaN = Number.isNaN || function(value) {
return value !== value;
}
Note: I prefer to test using #1 which works same all places and does not have dependency on latest JS also. (It always gives me correct result. No surprises!)
Detailed Explanation:
Here is our awesome NaN
NaN == NaN; // false
NaN === NaN; // false
Please don't blame JavaScript
for this, it is NaN which is supposed to behave this way in other languages also Which is fine as per rationale for all comparisons returning false NaN values
So comes isNaN
as our savior, but wait it acts little differently in some scenarios like
isNaN(undefined); // true
isNaN({}); // true
isNaN("lorem ipsum"); // true
I had some strange faces by seeing the results above. And here comes reason from MDN
When the argument to the isNaN function is not of type Number, the value is first coerced to a Number. The resulting value is then tested to determine whether it is NaN.
So how should we test NaN for the non-numbers variables at all? I always go by the following
if(x !== x) {
console.info('Is a NaN');
}
else {
console.info('Not a NaN');
}
ECMAScript-6/JavaScript-2015 Updates
Do we have anything in ECMAScript-6 for the same. Yup we do...
Number.isNaN(x); // true
The ES6 implementation will also be helpful for the above cases like
Number.isNaN(undefined); // false
Number.isNaN({}); // false
Number.isNaN("lorem ipsum"); // false
whereas ECMAScript-5 global function isNaN
outputs in true
for the above cases, which sometimes may not align with our expectation.