What is strange about NaN is that it does not equal anything, not even itself. Because of this it makes testing for NaN a little strange. There is a well supported native method called isNaN, but also Number.isNaN both of which work differently.
So to some extent isNaN works as expected, but it also returns true for values that are not NaN, such as undefined.
this behavior is not wrong in a way values like undefined, and null are Not Numbers, but it still may not really be the behavior that is expected.
So the Number.isNaN method works as expected if what is expected is for the method to return true only if the given value is NaN and only NaN.
The only problem with Number.isNaN is that it does not work on any version of IE, there is no support at all. So this is why it makes sense to use the isNaN methods given in a utility library like lodash.
When going vanilla js style with a project such a method might need to be part of your micro frame work. making a method to do this is not so hard, one way is to just return false if any type other than a Number is given, then convert to a String and test against the String ‘NaN’ in the off chance that the string ‘NaN’ is given then it will return false because it is a String. Whatever something like this.
This seems to behave like that of Number.isNaN, but will work on old browsers. It seems to work okay, but maybe you might prefer to use the method that exists in lodash that makes use of the fact that NaN is the only primitive value that does not equal itself.
Nice slick one liner.
Monkey Patching is generally frowned upon, but generally only if you are extending built in Objects with non standard methods. In this case monkey patching Number.isNaN support is just making sure that something that should be there is there.