[00:00:00]

>> Kyle Simpson: Here's a place where it is perpetually frustrating that we have
overloaded operators. We tend to think that curly braces must be scopes. They're
blocks, they're function bodies, they must be scopes. What's gonna happen when I
define an arrow function on line three?
>> Kyle Simpson: What is the parent lexical scope from which that arrow function
will go up one level to resolve the?

[00:00:30]

>> Speaker 2: Global?

>> Kyle Simpson: It is the global. It is not the workshop object because, guess
what? Just cuz there's curly braces around that object doesn't make it a scope.
Objects are not scopes. So this is a very common mistake that people have, and
there's hundreds of questions on Stack Overflow to this extent, where people are
saying, why is the arrow function not getting my workshop as my content?

[00:00:58]
Well, because workshop object's not a scope. You have to think about an arrow
function as not having of this and resolving it lexically. So what is the parent
scope? There's only two scopes in this program. The scope of the ask function,
which is an arrow, and the global scope.

[00:01:18]
There's no intervening scope in between.
>> Kyle Simpson: It is unfortunate that we've overloaded the curly brace that
confuses us into thinking it's a scope, but it isn't.
>> Kyle Simpson: So if you take all of this nuance around arrow functions and these
keywords. If you take it into account with my former comments on, I think arrow
functions, the downside is that arrow functions are anonymous and so they're a bit
harder to bug at times, they don't explain themselves well.

[00:01:55]
If you take the entire context, my perception is that the only time you should ever
use an arrow function is when you're gonna benefit from lexical this behavior.
Because the alternative to lexical this behavior is a hack like the var self equals
this case. Surely, some of you have seen code where you did var self equals this
and then you reference the cell.

[00:02:18]
Or maybe it was called var that or var underscore this, or whatever. Let me just
say, var self equals this is the worst possible name anybody ever could have come
up with. Because this keyword never, ever, ever, under any circumstances, points at
the function itself, it points at a context.

[00:02:42]
So if you absolutely must do the var self equal this hack, please do var context
equals this. Cuz that's what this keyword is, is a context, okay? But this arrow
function lexical this behavior is a much better way of doing it than a var self
equals this. And I would argue even better than doing the function.bind.

[00:03:10]
It is a much better way because it actually matches the mental model of what we
want. We want the this keyword to behave lexically here. We don't want for the
arrow function to have some magical this behavior to it. We want it to just adopt
the this keyword of some parent scope.

[00:03:27]
And that's what it does, so it is the right tool designed to fix the right problem,
if you're inclined to think correctly about it. So whereas I've said, generally,
don't use arrow functions, if you're in a case, like a couple slides ago with the
setTimeout, where you legitimately need lexical this, please use the arrow
function, cuz that's the right tool for the job.

[00:03:51]
As a matter of fact, I went so far as to write an ESLint rule, that requires your
arrow functions to make this references, it disallows any arrow function that is
not using lexical this. That's extremely controversial, I know, unlikely that very
many people are ever gonna use that ESLint rule.

[00:04:12]
But if you, like me, think that arrow functions have that purpose and that's what
they ought to be used for, that's a plug-in that will give you a rule to control
that behavior. Questions. Yes.
>> Speaker 3: Just to confirm. Going back one slide, so when we’re, when we would
be parsing this, workshop is going into the red bucket, it’s getting the global
scope.

[00:04:39]
The teacher property, though, would be scoped to-
>> Kyle Simpson: Properties aren't scoped, properties aren't lexical identifiers.
>> Speaker 3: Okay, got you.
>> Kyle Simpson: It's a member on an object value.
>> Speaker 3: Okay.
>> Kyle Simpson: It's not participating in lexical scope at all. My one and only
exception to the don't use arrow functions because they're anonymous, is use arrow
functions when you can benefit from the lexical this.

[00:05:03]
I will however say, that if you gonna use an arrow function to get your lexical
this, you need to combat those three downsides that we talked about with anonymous
function. You need to combat the downside that, anonymous functions don't have a
self reference, in case you need to do recursion or unbinding.

[00:05:21]
You need to combat the fact that they don't have a name. Use it in some way so that
it's gonna get a name inference, like, assign it to a variable or a property.
Because it's gonna show up as anonymous otherwise. And you need to have some way of
making it clear and obvious to the reader.

[00:05:36]
What is the purpose of this function? Don't make them read the function body to
figure that out.
>> Kyle Simpson: So now we've talked about the this keyword. We've seen all of its
different angles, and what I'm thrilled about actually is that the arrow function
is not a different rule for the this keyword.

[00:05:58]
I was afraid when they were adding arrow functions that we were gonna have to amend
these rules, and have a fifth rule to keep floating in our head, but it's not a
rule at all because the this keyword doesn't even apply instead of arrow functions.
The only thing you ever need to do to understand the this keyword is look for the
call site of a function that defines the this keyword, and ask those four rules.