The conclusion is that the parseInt of the Lodash world is map safe.

Famous map with parseInt bug

The famous parseInt bug in the front-end world:

['6'.'08'.'10'].map(parseInt);

// [6, NaN, 2]
Copy the code

Why is it safe to use Lodash’s parseInt, and the official example is given

_.map(['6'.'08'.'10'], _.parseInt);

// => [6, 8, 10]
Copy the code

Let’s start with Trim

The trim operation on arrays has been done recently.

['001100'.'110011'].map(val= > _.trim(val))
Copy the code

But then I thought why not write it this way, more succinctly:

['001100'.'110011'].map(_.trim)
Copy the code

As I was walking, I realized that trim has a second parameter, which is the target character for trim:

_.trim('110011'.'1')

/ / = > '000'
Copy the code

The subscript will be removed as a trim target. This is not possible:

['001100'.'110011'].map(_.trim)

/ / = > [' 11 ', '00']
Copy the code

But actually returned correctly, still [“001100”, “110011”]!

Why is that?

If you look at the lodash source code, there is a third secret parameter guard, which is a security parameter. Truthy omits the second parameter, so _. Trim is map safe.

The third parameter is not specified in the official documentation because:

The guard param is not intended for public use an is part of allowing it to work in _.map and others as an iteratee.

Github.com/lodash/loda…

It’s a bold guess that parseInt also has a third security parameter, and sure enough.

conclusion

Lodash trim and parseInt can safely be used as map handlers, and even a set of functions that will be consumed by a map are designed to be safe for LoDash.

Lodash is a powerful solution to many of the ills of native JS 👍.