Using lodash in chrome (latest as of today).
_.map("0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0".split(":"), parseInt);
i get:
[0, NaN, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Seems like a basic operation.
Using lodash in chrome (latest as of today).
_.map("0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0".split(":"), parseInt);
i get:
[0, NaN, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
Seems like a basic operation.
If you're already using Lodash, it's normally safer to replace native methods with Lodash ones when they exist.
In this case, I would use _.parseInt
instead of just parseInt
, as the latter may create unexpected results (as is the case here).
The following works as expected:
_.map("0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0".split(":"), _.parseInt);
If you're curious as to why the 'vanilla' parseInt
method returns NaN
, I believe that what is happening is the following:
_.map(collection, iteratee)
, the iteratee
is actually called with three arguments: (item, index, collection)
. Source here.parseInt
, the second argument is a radix that determines which base should be used to parse the integer (binary, octal, decimal, hexadecimal, etc.). Because the iteratee is called with three arguments, this messes up your radix and returns NaN
. See here for MDN's explanation on how parseInt
works._.parseInt()
avoids that problem by adding a guard. It's usually safe to assume that Lodash protects its methods with guards like this to make sure you can use them as iteratees in other Lodash methods.