Resolving this in Arrow Functions

[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.