Solving Scope with Arrow Functions

[00:00:00]
>> Will Sentance: So let's call our increment function one more time. I'm gonna talk through it, so that you don't have to. Okay, user1.increment. We call it, we look to user 1 for the increment method. It's not there, so we look to its dunder-proto, dunder-score, which links us up to the object the label prototype that sits on the object of user creator, that is user creator the function object combination, we grab the increment function, we create an execution context.

[00:00:32]
In it's local memory, we immediately assign the implicit parameter
>> Will Sentance: This that means implicit because we don't pass it in, the argument to fill it in, but it's always there. There it is this, and its argument, I guess you could call it its implicit argument, I guess, is whatever is to the left-hand side of the dot, user 1 okay?

[00:00:59]
Beautiful, and then we declare a function add 1. I'm not gonna go into exactly how these arrow functions work, but you can sort of see it's got no parameters. It's identical, basically. No parameters, no inputs. But its body says this.score++, okay? So we declare that arrow function. There it is.

[00:01:19]
I'm gonna do a little arrow above. That's how I'm gonna direct a special over function. It's an arrow function but it looks exactly the same. You run it by calling add one but it has one powerful difference. The this inside of its execution context. is going to refer to whatever the this was when it was defined.

[00:01:45]
I'm almost gonna do like this. It's got like a hidden property that says my this later on will be what it was when I was defined. So let's call it now. Add 1, new execution context set. First thing in my local memory of this new execution context.
>> Seth: This is assigned to user one.

[00:02:11]
>> Will Sentance: Excellent. The this is assigned to what the this was when this function was defined. When add1 was defined. And remember, when I say add1 was defined, that means literally, add1, never lose sight of this. That means, add1 was saved as a label in memory for that code.

[00:02:27]
Which means, you can certainly add hidden stuff to it, including a hidden property saying, when you call me, make sure my this assignment is to whatever this was when I was saved, okay? To user 1 and so now as Seth rightly said our this.score++ will evaluate to user1.score++ against all the odds because look, add1 is not called to the right hand side of a dot, so how the hell is this referring to the user1?

[00:03:00]
Because it was defined as an arrow function. All right, there it is. user1.score++. No user1 here. No user one here. User1 is out here. We increment it it's score. Okay folks, this is our new best practice for how to handle what is the very, very standard procedure of defining functions inside a method, calling them, needing to refer to the object at hand.

[00:03:25]
We're not running function inside of here to not refer to the object, but now we can easily refer to that object. Okay, people, yeah let's have thumbs on this, you lost me, I'm clear, I have clarifications. All thumbs up but yeah go ahead sir.
>> Seth: Are we taking a performance hit by declaring that function every time increment is called?

[00:03:48]
>> Will Sentance: I mean sure, but-
>> Seth: Assuming that incrementing the story is more difficult than it is here.
>> Will Sentance: Yeah, but you've got to balance always. First the performance here is going to be very minor in this situation. So firstly we're doing this in a situation where we would never put one line of code inside a function, but typically you may have 100 lines of code in this function, you wanted to structure them in such a way that they're easy to read.

[00:04:17]
Now does that mean that you're reassigning space and memory? Yeah. Does that make it more readable? Yeah. So there's always a trade off on that basis. So it's perfectly fair to stay yes, we're saving additional space for this new function definition. But if you go a hundred lines of code in this function, now I can split into a few sub functions.

[00:04:39]
Yes. I'm saving you space in memory but is far more readable
>> Seth: And add one is getting trashed every time
>> Will Sentance: And of course add one is absolutely being deleted. Once we leave this execution. Once we need is that
>> Seth: Unlike the first very first example where we kept those functions around on every object.

[00:04:54]
>> Will Sentance: Yeah, yeah, yeah, yeah. Totally different than that, absolutely. Absolutely. Absolutely. All right, good, good question from Seth, that sort of finessing around performance. We need to introduce arrow functions which bind this lexically. Lexical static scoping means where I was born, where I'm saved, determines something about me when I get called.

[00:05:15]
Well what is the thing? It's what my this assignment is. Lexical static determines where I was saved. Lexical means the positioning on the page, so where I was positioned, where I was saved determines something about me when I get called. Okay? All right, and that of course leads to the beautiful concept of Closure, the most beautiful concept in JavaScript, my favorite concept.