Deep JavaScript Foundations

# Implicit vs Explicit Coercion

This course has been updated! We now recommend you take the Deep JavaScript Foundations, v3 course.

Check out a free preview of the full Deep JavaScript Foundations course:
The "Implicit vs Explicit Coercion" Lesson is part of the full, Deep JavaScript Foundations course featured in this preview video. Here's what you'd learn in this lesson:

## Kyle reviews cases for when using double equals when coding.

Get Unlimited Access Now

Transcript from the "Implicit vs Explicit Coercion" Lesson

[00:00:00]
>> : Kyle Simpson: So some takeaways to avoid some of those weird cases. If you're gonna do a double equals comparison can either value, in other words either side of the double equals, be the actual true or the false value? If so I might humbly suggest you should avoid the double equals, okay.

[00:00:19] Or if either side can be the empty array, the empty string, or the zero value, you might want to avoid the double equals. Now that's only a few narrow cases actually, when you really think about all the places that might happen. If you go and look at your code and you think about it critically and you say what can come in here?

[00:00:39] It's not all the time that that's even gonna be the case. Now what about if you can't figure it out? What if you're like well I don't even know,err on the side of caution and avoid the double equals. But there's a whole bunch of places where you absolutely know what values are gonna come into that comparison.

[00:00:55] And if you do know, I think you should critically analyze, is it more important to use the double equals or the triple equals? We'll get to that.
>> : Kyle Simpson: Some examples of double equals, this is infinitely a long list but these double equals comparisons are entirely reasonable.
>> : Kyle Simpson: We already talked a little bit about this briefly, but there is an implicit coercion that happens in either direction between primitives and natives, we call it boxing and unboxing.

[00:01:30] We start with the string 123 and we call length on it, there's a boxing that happens to its string object counterpart. That's an implicit mechanism. I think that's a good thing cuz it makes that code less complicated because I don't have to explicitly cast it to a string object so that I can call the length operator, or the length property on it.

[00:01:49] The opposite direction is true, if for whatever crazy reason I already have the string object equivalent like do on line 6, on line 7 if I use an operator that needs the primitives, like the plus operator does It implicitly unboxes it to its primitive counterpart.
>> : Kyle Simpson: So in either direction the implicit mechanism helps make my code be less cluttered.