2 equal signs will coerce the second operand into the type of first operand then do a comparison of it can. so 1 == “1” is true. this leads to strange bugs.
3 equal signs do not do implicit type conversion, cuts down on weird bugs. 1===“1” is false.
It seems it is that way, which is weird. You should always convert to the widest type, meaning string for comparing numbers and strings. I just checked that 1 == "01" is true, which means that “01” gets cast to an integer. And according to the document it might be that for example 1 == "a" would basically be interpreted as 1 === NaN which is false.
2 equal signs will coerce the second operand into the type of first operand then do a comparison of it can. so 1 == “1” is true. this leads to strange bugs.
3 equal signs do not do implicit type conversion, cuts down on weird bugs. 1===“1” is false.
edit: it appears to be more complicated than that for double equals and the position of operands don’t matter. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Equality
Doesn’t it widen the types regardless of position? Meaning 1 == “1” will be compared as strings, not numbers.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Equality
mdn goes into it more and it’s way more involved than I thought, looks like order of operand doesn’t matter. see the number to string section
It seems it is that way, which is weird. You should always convert to the widest type, meaning string for comparing numbers and strings. I just checked that
1 == "01"istrue, which means that “01” gets cast to an integer. And according to the document it might be that for example1 == "a"would basically be interpreted as1 === NaNwhich isfalse.wow that seems super useful, thanks