imsabir

Posted on

# Javascript: [] ==![] is true ???

Array is equal not array:

[] == ![]; // -> true

Explanation:

The abstract equality operator converts both sides to numbers to compare them, and both sides become the number 0 for different reasons.

Arrays are truthy, so on the right, the opposite of a truthy value is false, which is then coerced to 0.

On the left, however, an empty array is coerced to a number without becoming a Boolean first, and empty arrays are coerced to 0, despite being truthy.

Here is how this expression simplifies:

+[] == +![];
0 == +false;
0 == 0;
true;

Follow @msabir for more such contents

EDIT: Per replies (and per the spec, which is authoritative), I was mistaken about this being a general rule.

The array on the left is actually coerced to a string of its elements joined with commas, rather than a number.

You can see this with these other examples:

[1, 2] == '1,2' // true
[1] == 1 // true, because 1 == '1'
['x', 'y'] == 'x,y' // true
[null, undefined, 1] == ',,1' // true - nullish values convert to ""
[null] == '' // true, same reason as above
[{}] == '[object Object]' // true

Alex Lohr • Edited

You're mistaken. The array is coerced with the internal statement of ToPrimitive(type on the other side), which in this case is the boolean that was previously coerced to number, see tc39.es/ecma262/#sec-islooselyequal - so it depends on what the array is compared with.

Granted, the post seems to wrongly imply that the coercion to number is always the case.

imsabir • Edited

Post is implies that it coerced to number. Thats correct its loselyequal implies thats for == and not for ===. so complete post is written with context of ==. Refer freecodecamp.org/news/js-type-coer...

Alex Lohr

I think the implication wasn't consciously made here. I am obviously aware this is about isLooselyEqual (==), because strict equality would not do any coercion whatsoever.

And here I put a link to the actual ecma standard that officially defines how JS is supposed to work in my answer that explains what is happening and you think you can refute that with freecodecamp?

I invite you to read the actual standard. It's a bit dry, complicated and sometimes slightly confusing, but it'll really help your understanding of the language.

imsabir • Edited

This blog is all about how isLooselyEqual (==).For much more in deep, context of blog will change. If this would not be about isLooselyEqual (==), then you might have find the === too. I completely agree with you and your context. And its really good part that, now our reader can get more depth knowledge that how == and === make the things different. But its completely different topic.

Alex Lohr

The main point here raised by lionel-rowe is the question why the array was coerced to number instead of string and the post did not answer that.

lionel-rowe

Sorry folks, I didn't mean to start a heated debate! I was mistaken, original article was indeed correct, even if it could have gone into a little more detail. I've edited my original post with a note.

imsabir • Edited

check []==0 //true, so, empty array is coerced to a number without becoming a Boolean first

imsabir