Equality

[00:00:00]
>> Kyle Simpson: Now let's talk about equality, the third topic underneath types and coercion. Let's talk about equality. You've probably heard about the double equals versus the triple equals. And you've probably heard, as most people say, that we should just avoid the double equals all together and only use the triple equals.

[00:00:15]
And the way that's usually explained is this, that the double equals will check the value loosely. And that the triple equals will check the value and the type, and that's called strict equality. It turns out that even though this is what most people say, it's not actually true.

[00:00:32]
It turns out that the difference between them is whether or not coercion is allowed. The double equals allows coercion when the types are different, and triple equals disallows coercion. And really that means that you can only use triple equals when the types are the same. So, it's interesting that people say never use the double equals.

[00:00:53]
They're basically saying, I don't want to let JavaScript convert from one type to another. I wanna always make sure that my types are the same. Really triple equals comes down to saying, I wanna do these checks but if I messed up and one of these things is not the type that I thought it was.

[00:01:09]
I want Java script to basically fail for me. And I don't think that's the best way to go about this. We don't want to not know what our types are. We wanna know what the types are. And if we know what the types are, then we can choose specifically whether we want coercion.

[00:01:25]
Whether it's helpful or not. So let me give you a couple examples. If I have studentName1 is Frank, and then I make studentName2. That's another string that has studentName1 in it. So I just went from a string to a string, no coercion happened there. Now, line four and five if I make workshop elements is 16, and I make workshop element two is 16 plus 0.

[00:01:48]
Both of those are numbers. So if I do studentName1 equal, equal studentName2, that is a string double equal to the string. And we know those strings are already equal cuz of how I assigned them. And if we did a triple equals, it's also gonna be true. And then if you look at line ten and 11, whether we use the double equals or the triple equals, they both result in true.

[00:02:13]
The point that I'm making is, that when the types are already the same, the double equals and the triple equals do exactly the same thing in 100% of all cases. No corner cases whatsoever. When the types are already the same, they do the same thing. And my advice to you as you go about this journey of learning about JavaScript more.

[00:02:35]
Is that you bring with you any habits that you may have from another programming language, if any that you actually do make your types more obvious. And if you're gonna do that, if you're gonna take the time and the effort to make sure that every comparison that you do that it's obvious that they're both strings.

[00:02:53]
Or that it's obvious, that they're both numbers. In those particular cases, double equals and triple equals are identical. There's no reason to avoid the double equals just because somebody said, hey, you should never use the double equals. It's only when they're different, it's only when the types are different that they have a different behavior.

[00:03:13]
And here you'll notice that actually the double equals can be more convenient, at least more easily readily readable. So I have a case where I'm comparing workshop1.topic whether it's null or undefined. And workshop2.topic whether it's null or undefined. And on lines four through seven I'm basically saying, can it be one or the other?

[00:03:37]
Can it be null, or can it be undefined, and I'm using the triple equals. But on lines 11 through 14, I'm doing the exact same kind of check, with the exact same outcome, but I'm using a double equals. And notice how much shorter that code is. Because I know that the double equals coercively checks null and undefined equal to each other.

[00:03:56]
And my claim is that lines 11 through 14 are not only the same functionally equivalent code, but that that is better code because it is more readable. And remember how I define better is because the reader is focused on the more important thing. The less important detail is whether or not there's this nuance in whether it was null or undefined.

[00:04:16]
That is an unimportant detail that distracts the reader in lines four through seven. The more important detail is, I'm asking, is workshop1.topic empty, and is workshop2.topic empty? So I would claim that lines 11 through 14 are focusing the reader on the more important thing. And by my definition, that makes the code better.

[00:04:38]
So that's one of the examples, there are more that we won't really fully dive into here. But that's one of the examples of why something like allowing Java script to take care of type conversions can actually improve our code.