Closure Introduction

[00:00:00]
>> Will Sentance: We're on to the beautiful concept of, the elegant concept of closure, as we involve lexical scoping and execution context. And the fundamental difference between them, that most of us don't really realize. But it's gonna be the backdrop on which closes it, so here we go, I think this is the most esoteric concept in JavaScript.

[00:00:21]
This is the bit that If you really understand, I think you'll get jobs, no doubt about it. This is a special bit, if you understand it as well, you can do some really powerful things. You can build professional level functions like once, this is a function that can turn other functions into functions that are gonna run once.

[00:00:38]
If they run them again, they don't work, and already, you might be thinking, hold on, that doesn't make sense, because I know how functions work. They don't remember anything from their previous running, they're brand new every time, we want that. And yet, hold on, I'm telling you they're gonna somehow remember they've been run before, and not run again.

[00:00:56]
We can achieve memoization, a core performance optimizer in, and this is something I talked about, you know, the most important asset now is developer time. I will say this memoization is still a go to practice for optimizing how we write our code, how performance it is. That's going to enable us to not repeat tasks, not repeat calculations that take a long time if we've done them before.

[00:01:18]
>> Will Sentance: Many jobs of design patterns like in the module pattern that use a node uses closure, and then, I just basically listed them all off here. Iterators, partial application, carrying, maintaining state in an asynchronous world, all of the rest on understanding closure under the hood, we're not going to implementing these things,.

[00:01:36]
You can go to all the hard parts, folks, about implementing all those things, actually that, you know,,we will be implementing a synchronous one. But they all depend on closure, so it all starts with us reminding ourselves of these principles we saw earlier on. I don't think we're going to go through and dive on how to get, can we take that?

[00:01:52]
No, we can't take that again, but, we do know that every time a function gets executed, run, invoke as an invocation, it creates a brand new local memory. Remember, a brand new execution context as a little temporary store memory, when we finish running that function, that's all deleted.

[00:02:09]
We run the function again, it doesn't remember the previous running, the data stored in the previous running of the function, In fact, it would be pretty old if it did. I don't want to run multiply by two with seven, and then kind of have a memory, a reverie over it previously being run with seven.

[00:02:26]
We want it to be fresh to run with ten, that's good, we don't want input number to sort of have an imprint of seven on it and I want to start fresh and it does. Functions never remember anything from their previous running, that local memory that gets created inside the running multiply by two, fresh every time.

[00:02:45]
And yet, what if we could have that function also have a permanent memory attached to it? That could change everything about how we write code, let's see, functions with memories. When our function gets called invoked,we create a little life store of data, we call it local memory, we might call it variable environment.

[00:03:07]
I didn't say this earlier on, but I'm gonna draw on for a sec, suppose I run multiply by 2 (7) here's local memory, in its local memory, I will find input number set to 7, okay. That local memory, when I finish running this function, that is deleted, except for the returned value.

[00:03:34]
Another name for that local memory is its variable environment, environment is the stuff around me, right? This my environment here, you're in my environment, where these are the variables, or constants, or functions that are in and around me inside this function, available to me inside the function. They also sometimes, by the way, call this local memory, I just wanna tell you this stuff now, as a bonus, they call it state.

[00:03:58]
Whenever you hear about the term state, it's one of those really bizarre terms, that just means, the live data at that particular moment, given moment in my application, that's being stored. So my application state, and at that point, my function's state is input number is 7, that's my state, that's it.

[00:04:15]
So we can call this the state as well of the function, when the function finishes running, its local memory is deleted, except for any returned value. But what if our functions could hold on to live data during their execution? What if I could have some of that data, not be deleted automatically, not be returned, but somehow persisted and held onto.

[00:04:40]
Such that the next time I run this function, it can have some memory, some remembrance of its previous execution, imagine what that would allow us to do. That would let our function definitions, the function definition itself, notice when we run it have a little memory. But the definition itself have a persistent memory attached like a permanent memory attached onto it.

[00:05:02]
That would be really, really special that would allow us to do things like say, you've previously run this function. I know that because in my remembrance of the previous running, I've stalled that you previously run me, so you can't run me again. So I can limit a function to only run one time and a thousand more things we're gonna see.