markdown guide

parseInt() takes to arguments, a string and a radix. I usually pass just the string I want converting as a number, you are passing both the string and the radix!

map gives us the value and the index (and the actual array)

["10", "10", "10", "10"].map( (value,index) => ... )

By just doing .map(parseInt) parseInt is taking both the value and the index.

Basically the second iteration is parseInt('10',1) and returns NaN.

Finally, to test that that's what happens, the following would return "0: 10" "1: 10" "2: 10" "3: 10"

function myFunc(value, i){
  console.log(`${i}: ${value}`)
["10", "10", "10", "10"].map(myFunc)
["10", "10", "10", "10"].map(parseInt)  ==>  [10, NaN, 2, 3]

This is because from Array.prototype.map

map calls a provided callback function once for each element in an array, in order, and constructs a new array from the results.
callback is invoked with three arguments: the value of the element, the index of the element, and the Array object being traversed.

Also from parseInt()

Syntax: parseInt(string, radix);

So when this is executing it will return

    parseInt("10", 0),
    parseInt("10", 1),
    parseInt("10", 2),
    parseInt("10", 3)

take a list of strings that represent numbers and return a new list with all the strings converted to the numbers they represent, but they now have the data type of number


if you execute this statement, the result will be [10, NaN, 2, 3]. Why?
But if you use parseFloat instead of parseInt, you will get the list of numbers.
I can't really explain why this is happening. But you can use this one as a replacement:

["10", "10", "10", "10"].map(function(x){ return parseInt(x); })

whoa, you're right. Can someone explain what is happening?

I usually write map functions like this

["10", "10", "10", "10"].map(item => parseInt(item));

and that does indeed return [10, 10, 10, 10].

passing just parseInt as a callback.. how does it know what arguments to take?

Classic DEV Post from Jun 14 '19

Unit and Integration Testing

Writing effective Unit and Integration Tests begins with writing TESTABLE code. When moving toward a Continuous Development / Continuous Integration pipeline, there needs to be solid testing to show that the code works as expected. This article will have a front-end focus, but the concepts can certainly be applied in other areas.

Theofanis Despoudis profile image
Senior Software Engineer @teckro, Experienced mentor @codeimentor, Technical Writer @fixate.io, Book author

Great software developers built here

Sign up 🦄