Difference in efficacy between parseInt() and Number.isInteger() in following Javascript array scenario?

Question

I am working through freecodecamp.org's Javascript ES6 coding problems and one of them tasked me with using arrow function notation to:

1. Take an array of real numbers.
2. Filter only the positive integers into a new array, and
3. Square those positive integers.

I have successfully completed the problem but built my code for Step 2 by filtering the original array with Numbers.isInteger(). Freecodecamp.org's provided answer utilizes parseInt().

I do not see why we would need to parse integers if they are already integers, nor why parseInt() does not throw an error since its parameter asks for a string.

My primary question: Are both equally acceptable? Is one going to get me into more trouble down the road?

The only closely relevant stackoverfow I found was here (which was vaguely helpful). Below is my code followed by the answer code provided by freecodecamp.org. NOTE: I am aware my code has a few extra steps in it. I am not a huge fan of arrow notation and am still improving my code-organization!

---

MY CODE::

const realNumberArray = [4, 5.6, -9.8, 3.14, 42, 6, 8.34, -2];

const squareList = (arr) => {

"use strict";

// dictates what numbers are filter()'d out of original array

const checkElement = (value) => value > 0 && Number.isInteger(value) == true;

const integersOnly = arr.filter(checkElement); //filters ONLY positive integers into new array

---

PROVIDED ANSWER CODE::

const realNumberArray = [4, 5.6, -9.8, 3.14, 42, 6, 8.34, -2];

const squareList = (arr) => {

"use strict";

const squaredIntegers = arr.filter( (num) => num > 0 && num % parseInt(num) === 0 ).map( (num) => Math.pow(num, 2) );

Answer 1

The docs are a little bit misleading - the first parameter to parseInt doesn't have to be a string. Looking at the specification, the first argument gets cast to a string as the first step:

When the parseInt function is called, the following steps are taken:

1. Let inputString be ToString(string).

One of the problems with parseInt is that, if it has a leading zero, it may be interpreted as octal in some (old) browsers, and as base 10 in other (newer) browsers. For this reason, if you want to support said old browsers, it's best to either always provide a radix (as the second parameter) or use Number instead.

That said, in this particular situation, it makes no difference, because calling parseInt on a number will never result in a leading zero.

Still, I think the recommended answer is a bit misleading - since you know that the numbers used in the test will always be positive, it would be a bit more appropriate to use Math.floor than parseInt for this purpose, since you're just trying to get the floored value, not trying to turn a string into a number.

Answer 2

parseInt tries to convert the value you pass to it into an integer, if you call it with this parameter parseInt("30") it will return to you the value 30 as a number. If you call it with a value that can't be converted to a integer like parseInt("hello world") it will return NaN.

Number.isInteger validates if the given value is an integer returning a true or false boolean value. Number.isInteger(1) will return true, Number.isInteger("hello world") or Number.isInteger(3.14) will return false.

Answer 3

I do not see why we would need to parse integers if they are already integers.

You don't need to. This is abuse of parseInt. They should have used Math.floor instead for their intented purpose.

Why parseInt() does not throw an error since its parameter asks for a string?

Because it's an old API, and it's very lenient. Instead of throwing errors, it simply coerces its argument to a string, then tries to parse that.

My primary question: Are both equally acceptable?

No, parseInt is absolutely inacceptable. You found a much better solution with isInteger. The reason why they didn't use it probably is that isInteger is a relatively new function, added with ES6.