В чем разница между lodash toNumber и parseInt? - PullRequest
0 голосов
/ 11 июня 2019

Я знаю, что Lodash часто добавляет некоторые дополнительные проверки или тонкости к функциям, которые уже существуют в JavaScript, но не ясно, что конкретно делает _.toNumber, чего бы я не получил с parseInt.

Я бы предпочел использовать Lodash только тогда, когда он предоставляет преимущества, которых нет в существующих функциях JavaScript, но я не вижу ничего в этом случае.

Ответы [ 2 ]

2 голосов
/ 11 июня 2019

_.toNumber преобразует данный ввод в число, если такое преобразование возможно, в противном случае возвращает NaN.Методы parseInt и parseFloat также работают таким же образом (хотя первые будут возвращать только целые числа), однако они намного более слабы в своих правилах синтаксического анализа._.toNumber значительно более строгий.

Например, с тем же вводом '5.2a', parseInt вернет 5, parseFloat вернет 5.2, а _.toNumber вернет NaN.Первые два игнорируют все после первого нераспознанного символа и возвращают число, образованное всеми проанализированными символами, до этой точки.Однако последний возвращает NaN, если встречается нераспознанный символ.

_.toNumber сопоставим и функционально аналогичен Number функции.

1 голос
/ 12 июня 2019

Я думаю, что гораздо лучше просто взглянуть на источник _. ToNumber , и это практически ответит на ваш вопрос:

function toNumber(value) {
  if (typeof value == 'number') {
    return value;
  }
  if (isSymbol(value)) {
    return NAN;
  }
  if (isObject(value)) {
    var other = typeof value.valueOf == 'function' ? value.valueOf() : value;
    value = isObject(other) ? (other + '') : other;
  }
  if (typeof value != 'string') {
    return value === 0 ? value : +value;
  }
  value = value.replace(reTrim, '');
  var isBinary = reIsBinary.test(value);
  return (isBinary || reIsOctal.test(value))
    ? freeParseInt(value.slice(2), isBinary ? 2 : 8)
    : (reIsBadHex.test(value) ? NAN : +value);
}

Как вы можете видеть, он делает кучу других вещей по сравнению с parseInt . Чтобы быть более конкретным:

console.log(_.toNumber(1),       parseInt(1))        // same 
console.log(_.toNumber('1'),     parseInt('1'))      // same  
console.log(_.toNumber('b'),     parseInt('b'))      // same  
console.log(_.toNumber({}),      parseInt({}))       // same 
console.log(_.toNumber(' 1 '),   parseInt(' 1 '))    // same
console.log(_.toNumber([1]),     parseInt([1]))      // same
console.log(_.toNumber(' 1a1 '), parseInt(' 1a1 '))  // NaN      1
console.log(_.toNumber([1,2]),   parseInt([1,2]))    // NaN      1
console.log(_.toNumber(false),   parseInt(false))    // 0        NaN
console.log(_.toNumber(!0),      parseInt(!0))       // 1        NaN
console.log(_.toNumber(!!0),     parseInt(!!0))      // 0        NaN
console.log(_.toNumber(5e-324),  parseInt(5e-324))   // 5e-324   5
console.log(_.toNumber(5.5),     parseInt(5.5))      // 5.5      5
console.log(_.toNumber(null),    parseInt(null))     // 0        NaN
console.log(_.toNumber(Infinity),parseInt(Infinity)) // Infinity NaN
<script src="https://cdnjs.cloudflare.com/ajax/libs/lodash.js/4.17.11/lodash.min.js"></script>

Итак, для суммирования _.isNumber дает вам больше expected / consistent, и я бы поспорил с результатами safer, когда дело доходит до разбора ввода с массивами, десятичными числами, ложными значениями и строками. Было бы проверить весь ввод против parseInt, который заботится только о первом действительном значении, как вы можете видеть из примеров выше. Он также лучше обрабатывает оператор отрицания (!) и т. Д.

Так что в целом у него есть свои применения против parseInt

Примечание : Здесь есть ошибка: _.toNumber и parseInt возвращают NaN для undefined, что, учитывая, как _.toNumber работает с остальными ложными значениями, можно ожидайте возврата 0 против NaN:

console.log(_.toNumber(undefined), parseInt(undefined))  // NaN NaN
...