Stuff I Had Wrong
Admittedly this seems like a fairly negligible distinction in terms of practicality. But if you’re concerned about technical accuracy in the way you describe things, then it’s an important distinction to make.
The “this” Identifier Refers to the Function Itself
I had always thought that
this refers to the function in which it lives. But that’s not how it works. As Kyle explains it,
this “usually points to an
object. But which
object it points to depends on how the function was called.” I’ll take his examples straight from the book because they do most of the explaining:
The four techniques shown here demonstrate the four rules that determine what
this refers to. It’s all about how the function was called.
”===” Checks for Type Equality
== checks for equality of the value only, while
=== checks for equality of both the value and type.
42 == "42" //true, but
42 === "42" //false. But this isn’t actually what’s going on. While it’s true that
42 === "42" is false, it’s not because the
=== is checking for type; it’s because
=== is checking for value equality without coercion allowed.
Coercion is the process of converting from one type to another. When you use the
== comparison with different types - like
42 (a number) and
"42" (a string) - JS sees that they’re different types and begins coercing one or both values until the types match. But when you use
=== to compare two values of different types, this coercion step never occurs. Thus it should be thought of that
== checks for value equality with coercion allowed, and
=== checks for value equality without coercion allowed.
Is this splitting hairs? Possibly. But again, I find it valuable to truly understand what’s happening with my code and to be able to describe it accurately. Saying that
=== checks for “type equality” is a technical mis-characterization which I’m glad has been set straight for me.
Two Arrays with the Same Contents Are == Equal
They are, in fact, NOT equal:
Despite that fact that the values of both
b are arrays with the same contents, they are still references to different arrays. And that’s the key - we’re not comparing two sets of contents, we’re checking if two
objects are the same object. Obviously
a is different than
b, so they’re not equal.
Some of you may be saying “duh” on this one, but it just never occurred to me.
This should be
NaN property is a symbol, similar to infinity, that describes a concept rather than a value. More specifically, it describes what something isn’t (not-a-number), rather than what something is. If value A isn’t a number and value B isn’t a number, is value A necessarily equal to value B? Of course not.
There are some behaviors of JS that are legit quirks (
typeof(null); // "object" what? ), but this isn’t one of them.