Some JavaScript facts

[u/hsnice]

[u/senocular]

"When we compare two values using "==", And both values are of different types, then javascript tries to convert the type of one value.

This is not entirely true. In some cases both values are converted, for example with string-boolean comparisons. In that case both are converted to numbers.

"2" == true // false
"true" == true // false
// because
Number("2") == Number(true) // false
Number("true") == Number(true) // false
// and not
Boolean("2") == true // true
"true" == String(true) // true

There's also an exception with undefined/null comparisons:

document.all == undefined // true
document.all == null // true

[u/hsnice → u/senocular]

Oh! okay, thanks.

And what I think is that when we compare using '==', it always converts both values in number.

"true" == true   // false  

Number("true")  // NaN  

"0" == false  // true
  
Number("0")   // 0
  
Number(false)  // 0  

"1" == true  // true

Number("1")  // 1 
 
Number(true)  // 1

[u/senocular → u/hsnice]

As a general rule, yes, though not when comparing values of the same type (string to string or bool to bool, etc.).

"1" == true // Number("1") === Number(true)
// but
"a" == "a" // "a" === "a"

Also when you compare an object with a primitive, the object will first go through a more generic "to primitive" conversion first before the comparison is made. If no primitive is derived, an error is thrown. Otherwise that object's primitive value will go through the normal comparison treatment which may include converting to a number if not the same type of the primitive to which its being compared.

1 == Object.create(null) // Error
1 == { valueOf() { return "1" } } // true

Finally, Symbol primitives only == themselves (including object-wrapped versions of themselves).

const sym = Symbol('sym')
sym == Symbol('sym') // false
sym == sym // true

sym == Object(sym) // true (since Object(sym) to primitive is sym)

[u/hsnice → u/senocular]

Great Explanation!! Thanks

[u/Heavy_Hole]

I never use the double equal operator, why would any want to? The triple equal operator is way better because it does strict equivalence. Use typeof if you are trying to determine the data type. Honestly unless I was debugging or reading someone's code I would never have to know a thing about the loose double equal sign. And to tell you the truth I would either rewrite what I saw or just walk away from the codebase because that coder either doesn't give a shit or has terrible preferences for what is considered good practice. For anyone learning JS stay away from the double equal operator and use the stricter triple equal operator. It WILL introduce bugs into your code because of its loose equivalency.

[u/[deleted] → u/Heavy_Hole]

Agreed, I’m very new but I remember a situation where I could have easily used double equals to compare a string with a number inside the double quotes, but instead used triple equals and compared it to Number() and then the value I was plugging in for comparison just because I disliked double equals so much…it was more verbose but it just didn’t feel right exploiting one of JS’s strange logical anomalies.

[u/inabahare → u/[deleted]]

At my workplace we have linter rules agains == and youre doing gods work avoiding it!

[u/Heavy_Hole → u/[deleted]]

You made the right move, because what happens when something else passes through, let's say you where checking to see if it was equal to zero and false got passed through, that would be true since the boolean false you pass would be converted to a 0. Double equals introduces lots of opportunities for bugs.

[u/ccrlop]

Keep it flowing. Thanks 👍😊

[u/[deleted]]

Also logically, its not a good idea to use nulls in place of 0s. 0 is a known quantity, where as null is simply unknown.

I've seen where people default to 0s on isnull in sql, then average it out on the front end and wonder why its all fucked up, instead of filtering those nulls out either in te query or using a simple filter function in js..