I’m down a rabbit hole. I understand that NaN cannot equal itself, hence the birth of the isNaN
function;
isNaN('hello' / 2); // true
isNaN(2) // false
I also understand that isNaN()
first coerces the value you pass it, and then it sees if the value is NaN
.
However, I keep reading about the “pitfalls” of isNaN()
, and here is the one that is always referenced:
isNaN('hello') // true
How is that bad behavior? I thought a string, in this case, 'hello'
, is indeed not a number?
So, often times, the article points to this as the solution:
Number.isNaN('hello') // false
But, tell me, why is that better? A string isn’t a number! How does this solve anything?
Number.isNaN()
doesn’t coerce, it simply reports back if the given value is, as it stands, a number. Of the two, this is to be preferred, as coercion is hinky at best. Not sure what articles you read, but take a look at these two:
https://devdocs.io/javascript/global_objects/isnan#Description
https://devdocs.io/javascript/global_objects/number/isnan
I think the “You Don’t Know JS: Types & Grammar” Special Numbers section does a pretty good job of explaining it.
Special Numbers
NaN literally stands for “not a number”, though this label/description is very poor and misleading, as we’ll see shortly. It would be much more accurate to think of NaN as being “invalid number,” “failed number,” or even “bad number,” than to think of it as “not a number.”
Fun fact:
const word = 'Do math with me you can not'
Number(word);
NaN
typeof Number(word) === 'number'
true
1 Like
Brilliant. Kyle Simpson is really good at explaining these concepts. Thank you for the reference. This is what made it stick for me.
1 Like