DEV Community

John Au-Yeung
John Au-Yeung

Posted on • Originally published at thewebdev.info

Why Should We Be Careful of JavaScript Type Coercion?

Check out my books on Amazon at https://www.amazon.com/John-Au-Yeung/e/B08FT5NT62

Subscribe to my email list now at http://jauyeung.net/subscribe/

Type coercion can be a convenience feature or a trap in JavaScript. Learn why here.

Since JavaScript is a dynamically typed programming language, data types of objects and variables can change on the fly. This a problem that we’ll face often as we write more and more JavaScript programs. There’re a few things to be aware of with type coercion, which is the conversion of data types on the fly during program execution.

Type Coercion

As we mentioned, type coercion is the changing of data types on the fly. It happens when data doesn’t match the expected type. For example, if we want to manipulate numbers and string with numbers, we can write:

2*'5'
Enter fullscreen mode Exit fullscreen mode

and we get back 10.

This may seem like a great convenience feature, but it also sets up lots of traps we can fall into. For example, if we have:

1 +'1'
Enter fullscreen mode Exit fullscreen mode

We get:

"11"
Enter fullscreen mode Exit fullscreen mode

which isn’t what we want.

JavaScript has type coercion also because the language originally didn’t have exceptions, so it returns some values for doing invalid operations. Examples of these values include Infinity or NaN , which are return when we divide a number by 0 or try to convert something that doesn’t have numerical content to a number respectively.

NaN stands for not a number.

For example, we get that:

+'abc'
Enter fullscreen mode Exit fullscreen mode

if NaN since it tries to convert the string 'abc' into a number unsuccessfully, so instead of throwing an exception, it returns NaN .

More modern parts of JavaScript do throw exceptions. For example, if we try to run:

undefined.foo
Enter fullscreen mode Exit fullscreen mode

Then we get ‘Uncaught TypeError: Cannot read property ‘foo’ of undefined.’

Another example would be mixing number and BigInt operands in arithmetic operations:

6 / 1n
Enter fullscreen mode Exit fullscreen mode

Then we get ‘Uncaught TypeError: Cannot mix BigInt and other types, use explicit conversions.’

How Does JavaScript Type Coercion Work?

Type coercion is done within the JavaScript interpreter. There’re functions built into almost all browsers to do this. We have the Boolean for converting values to boolean, Number to convert values to numbers and so on.

Avoiding Type Coercion Traps

To avoid falling into traps caused by type coercion, we should check the type of the object and convert it to the same type before operating on them.

Number

For example, we use the Number function to convert anything into numbers. For example, we can use it as follows:

Number(1) // 1
Number('a') // NaN
Number('1') // 1
Number(false) // 0
Enter fullscreen mode Exit fullscreen mode

The Number function takes an object of any type as the argument and tries to convert it to a number. If it can’t, then it’ll return NaN .

We can also use the + operator in front of a variable or a value to try to convert it to a number. For example, we can write:

+'a'
Enter fullscreen mode Exit fullscreen mode

Then we get NaN . If we write:

+'1'
Enter fullscreen mode Exit fullscreen mode

Then we get 1.

String

To convert objects to a string, we can use the String function. It also takes an object and tries to convert it into a string.

If we pass in an object, we get back:

"[object Object]"
Enter fullscreen mode Exit fullscreen mode

For example, writing:

String({})
Enter fullscreen mode Exit fullscreen mode

will get us that.

Primitive values will get us the string with the same content as the primitive value. For example, if we write:

String(123)
Enter fullscreen mode Exit fullscreen mode

We get “123” .

All Objects other than ones we specifically remove the prototype from will have a toString method.

For example, if we write:

({}).toString()
Enter fullscreen mode Exit fullscreen mode

We get “[object Object]” back.

If we write:

2..toString()
Enter fullscreen mode Exit fullscreen mode

Then we get back “2” . Note that we have 2 dots since the first dot designates the number as a number object and then the second dot lets us call methods on the number object.

Other weird conversions involving strings that can’t be explained with reason include:

`"number" + 1 + 3        // 'number13'
1 + 3 + "number"        // '4number'
"foo" + + "bar"         // 'fooNaN'
`{}+[]+{} // '[object Object][object Object]'
`!+[]+[]+![]             // '`truefalse'
`[] + null + 2           // 'null2'`
Enter fullscreen mode Exit fullscreen mode

Symbol.toPrimitive

Objects also have the Symbol.toPrimitve method that converts an object to a corresponding primitive value. It’s called when the + unary operator is used or converting an object to a primitive string. For example, we can write our own Symbol.toPrimitive method to convert various values to a primitive value:

let obj = {
    [Symbol.toPrimitive](hint) {
        if (hint == 'number') {
            return 10;
        }
        if (hint == 'string') {
            return 'hello';
        }
        if (hint == 'true') {
            return true;
        }
        if (hint == 'false') {
            return false;
        }
        return true;
    }
};
console.log(+obj);
console.log(`${obj}`);
console.log(!!obj);
console.log(!obj);
Enter fullscreen mode Exit fullscreen mode

Then we get:

10
hello
true
false
Enter fullscreen mode Exit fullscreen mode

from the console.log statements at the bottom of our code.

Avoid Loose Equality

Loose equality comparison is done by the == operator. It compares the content of its 2 operands for equality by converting to the same type before comparison. For example,

1 == '1'
Enter fullscreen mode Exit fullscreen mode

will evaluate to true .

A more confusing example would be something like:

1 == true
Enter fullscreen mode Exit fullscreen mode

Since true is truthy, it’ll be converted to a number first before comparing them. So true will be converted to 1 before comparing, which makes the expression true.

To avoid a confusing situation like this, we use the === comparison operator instead.

Then

1 === '1'
Enter fullscreen mode Exit fullscreen mode

and

1 === true
Enter fullscreen mode Exit fullscreen mode

will both be false , which makes more sense since their types are different. No type coercion will be done by the === operator on the operands. Both the type and content are compared.

Comparison issues we mentioned above apply to primitive values. Object are compared by their reference so if the operands have a different reference then it evaluates to false no matter which operator we use.

With these functions, we converted our variables and values to the type we explicitly have written. It makes the code much more clear and we don’t have to worry about the JavaScript interpreter trying to convert things into a type that we don’t want. Also, we should use the === operator instead of the == operator to compare primitive values.

Top comments (0)