I’m down a rabbit hole. I understand that NaN cannot equal itself, hence the birth of the
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
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:
I think the “You Don’t Know JS: Types & Grammar” Special Numbers section does a pretty good job of explaining it.
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.”
const word = 'Do math with me you can not'
typeof Number(word) === 'number'
Brilliant. Kyle Simpson is really good at explaining these concepts. Thank you for the reference. This is what made it stick for me.