|
|
|
|
|
by 6510
665 days ago
|
|
If incompetent it provides a way to be sure? Could you for laughs explain for which cases these are, why they are needed and why they did it this way? 1) num-num === 0 2) num.trim() !== '' 3) Number.isFinite(+num) 4) isFinite(+num) 5) return false; 6) Why this specific order of testing? Why prefer Number.isFinite over isFinite? https://www.npmjs.com/package/is-number module.exports = function(num) {
if (typeof num === 'number') {
return num - num === 0;
}
if (typeof num === 'string' && num.trim() !== '') {
return Number.isFinite ? Number.isFinite(+num) : isFinite(+num);
}
return false;
};
I would have just.... isNumber = num => isFinite(num+''.trim());
Why is that not precisely the same? (it isn't)how about... function isNumber(num){
switch(typeof num){
case "number" : return !isNaN(num);
case "string" : return isFinite(num) && !!num.trim();
}
}
Is there a difference?IMHO NPM should have a discussion page for this. There are probably interesting answers for all of those looking to copy and paste. |
|
Only the fact that you can write a bunch of slightly different versions because of Javascript's flaws/features should be a sign that you just can't grab an arbitrary implementation and hope it matches your use case, and especially not if you don't/can't pin the version.