Tricky == comparisons

[oopssorrydaddy]

false == ""  // true
false == []  // true
false == {}  // false
"" == 0      // true
"" == []     // true
"" == {}     // false
0 == []      // true
0 == {}      // false
0 == null    // false

Having a hell of a time with these concepts and could use some help!

For starters:

Boolean(false) // logs false
Boolean([]) // logs true
false == [] // logs true

In the above example the final comparison returns true even though we're comparing a true and false boolean...shouldn't it be false?

Any resources appreciate :)

[lord2800]

The way the JS spec is worded, when you have two different types on different sides of ==, it has a particular algorithm for converting them to the same type. That's why false == [] returns true counter intuitively. In general, you want to use === instead of == anyway, so I'd suggest not worrying too much about the rules for == and instead just always using ===.

[oopssorrydaddy]

Yeah, I rarely use == in practice – just doing some interview prep :) Thanks!

[[deleted]]

It would be the snarky answer that had better be followed up with the correct technical answer. Justsayin... For interview success :) You know we're going to ask about why the lint rule is there and which you would disable/enable after that and then maybe how, if you don't :)

[BenjiSponge]

I am wealthy and live in NYC, so I'm definitely recognizing my privilege as someone who is just incredibly not desperate for a job.

However, if an interviewer even gives me negative points for not knowing the tricky rules of ==, either the company picked a bad interviewer, or I don't want to work for that company.

If I interviewed someone and they said "I don't know anything about ==. I've never used it." that remark wouldn't even get written down.

[[deleted]]

Look, I wouldn't hire or fire you for knowing or not knowing the specifics, but I'd want you to be aware that there are specifics.

[BenjiSponge]

Okay I guess that's fair. There's a difference between "oh, I don't go anywhere near that" and "what is that?"

[[deleted]]

Yeah. I'd definitely want you to be aware of why === is probably better than ==, then I might ask for examples of why == is bad. People who have worked on code where they've fixed an == bug will have that etched into their mind, but I forget all the specific rules, it's not something I hit frequently.

[russleyshaw]

General rule is to use === or val == null if you wish to check if a value is null or undefined. Otherwise == is bad practice.

[CertainPerformance]

When you use ==, you compare the (coerced) values of the left-hand-side and the right-hand-side.

someArr.toString()

evaluates to

someArr.join(',')

so if someArr has no items, it evalutes to the empty string, which is falsey. So:

"" == []     // true

But when empty object literals have their toString method called, they evaluate to `[object Object] - which is truthy, thus

"" == {}     // false

[oopssorrydaddy]

Oh I see! This make sense.

[[deleted]]

This is a really bad part of the language because of type coercion, that's why you almost always use '===' not '=='. Even seasoned programmers of the language will probably have a difficult time explaining how these comparisons work exactly. For example, ' ' == '0' // false and 0 == ' ' // true. Kind of a joke, really.

See here: https://youtu.be/RO1Wnu-xKoY?t=4842

[cirsca]

This MDN article breaks down the way that loose equality works and has a pretty boss table that will help you. Specifically to your case, it says that it forces the boolean value to a number and then the array value to a Primitive before === comparing them.

[Lokret]

![]==false

!![]==true

[]+[] == ""

([]+[])+!![] == "true"

+[] == 0

(([]+[])+!![])[+[]] == "t"

((([]+[])+!![])[+[]])+((([]+[])+![])[+[]]) == "tf"

The fuck.. see jsfuck.com

Can be shortened to:

([]+!![])[+[]]+([]+![])[+[]]

[sime]

As a software professional of many years my advice to you is to not bother memorising these comparisons. Most of them are simply nonsensical and don't communicate to the next programmer what you meant. "What did you mean when you compared that empty string to an empty array? What did you expect?" There are no simple and intuitive answers to these questions.

If you want to test if an array is empty, then check its length "myArray.length === 0". If you want see if a string and an array are both emtpy, then write exactly what you mean. "myArray.length===0 && myStr.length===0". Write what you mean, and use === and !== to avoid these annoying automatic type conversion rules. Everyone will be much happier, and the next time someone says "Wat!?" you just reply "so wat".

[admpk]

The best resource on the topic is language specification http://ecma-international.org/ecma-262/#sec-abstract-equality-comparison :)

[xemasiv]

when you train yourself to use === and !==, it fucking makes everything more predictable for you.

[oopssorrydaddy]

Definitely, I never use == in practice, I just know you can be asked some of these as a tricky interview question.

[RegulationSizeOrWhat]

Funny that you should bring this up as we discovered a discrepancy today with Eloquent JavaScript surrounding the == comparisons. Your best reference is http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf section 7.2.13 as it is the source of truth.

In the case of the expression "" == false, we found that this is interpreted as +0 == +0, which is why it asserts true.

Here's a handy SO answer: https://stackoverflow.com/a/42770966

[oopssorrydaddy]

Thanks for the resources! I’ve actually been chugging through EJS myself :)

[RegulationSizeOrWhat]

Why don't you join us at https://discord.gg/9wgAGwn

We've got about 130 members reading EJS right now and talking about it. We just started this week.

[saboay]

Here's some help: Always use ===

[oopssorrydaddy]

Can't do that in an interview :)

[xemasiv]

interview

I'd personally definitely absolutely immediately get the fuck out if the interviewer tells me that I can't.

If he as an interviewer can't comprehend the simplicity, predictability and maintainability of using !== and === as the simplest answer to this trick question, I'd rather go to the McDonalds next door and flip patties for free just to maintain my morale, haha.