Closure

[00:00:00]
>> Will Sentance: Here we go, people, we are going to do closure. So we've hit our principles, we mapped them out, we hit our higher-order functions, the ability for our functions to get edited live when we use them with more specific code, that was lovely. Turns out higher-order functions aren't just about passing in a new function as input, when we call it, that allows us to specify some of the details of what the function does, they're also about returning out a function from another function, and it turns out when we don't just input a function into a higher order function, we don't have to say it's higher order, it's just a function that takes in a function, or returns one out.

[00:00:39]
It turns out when we return out a function from another function, we get one of the most powerful features in JavaScript. I can't really stress enough, it's going to allow us to use fantastic functions like once and memorize. Which are really standard best practice functions, once is going to allow us to limit how many times a function can be called, memorize is going to save us from redoing computationally demanding work with a function once we've done that work before, but also many of our design patterns in JavaScript, including the module pattern, and including the built-in modules of JavaScript, all implement their features with closure.

[00:01:20]
And then we mentioned iterators earlier, the ability to go through a set of data, or sorry, an array, a list of data, and rather than hit it via our rather strange interface for data, the for loop, instead hit that array via a function where each time we run it, its return value is the next element in that array, that function is going to depend on closure, partial application, a big part of functional programming, and particularly the ability for JavaScript's asynchronicity to function, that is that when I start a task that's going to take a long time, speak to the internet for example, speak to a server, speak to an API when I get that data back from the internet to use, let's say I've got a, no I'm not going to say Twitter, a Spotify app, a TikTok app.

[00:02:16]
That's not controversial, oh, is it, I don't know. A TikTok app, TikTok app, that when I go and get my list of videos, at that moment, I want to run some code. That's going to be my asynchronous callback, we'll see all this play out, but will that callback, will that function have the data it needs in order to run when the function gets called back? It will because of closure. Everything depends on this elegant structure.

[00:02:59]
But it all starts from a point of great similarity where we started a couple of hours ago, which is, when we run a function, we created a brand new execution context, when we called multiply by 2 with 7, brand new execution context with its own temporary local memory, just for the data inside that function, when we finished running, multiply by 2 the first time with 7, we threw it out. Except for the return value, which got returned into output.

[00:03:33]
We then ran multiplied by 2 again with input of 10. We did not want to remember the previous running was with 7. I don't want to know that it was run with 7 before, I want a fresh start. Every time a function gets run, we create a new local memory. It's temporary for only while we're running that function. We add it to the call stack, when it's finished running, the only thing, hopefully, as long as that function is pure, doesn't have side effects, the only consequence will be within that function, and then the return, sorry, the only consequence will be the output via the return value.

[00:04:07]
That's what we want to have happen, cause that makes our functions predictable. When I run multiply by 2 with 7, I can run it anywhere in my code, its consequence is only going to be the return value and any work inside is going to be bundled up, locked inside that function core. Beautiful. What if we had functions that could remember their previous running, their previous invocation. When our function gets called, we create a live store of data, local memory, sometimes poshly called the variable environment, the place, environment is the stuff around me.

[00:04:42]
So it's the variables, the content, the data that's available around me inside that function, or state, that's the fancy word for data at that moment in my application. So it's the data around me in the function for that function's execution context. When the function finishes executing, running, its local memory is deleted, besides the return value. But what if our functions could hold onto live data between executions?

[00:05:11]
Between their runnings, they could somehow not only have a temporary memory, but also a persistent memory. Maybe even one that's only available inside of that function. That would be pretty powerful. This will let our function definitions, the function that we've saved to then run, we save it once, run it again and again and again and again, we could allow it not only to create a new local temporary memory each time, but a persistent one that maybe sits alongside its definition that we can access again and again.

[00:05:45]
That would be pretty remarkable. It would allow us to change the behavior of our functions to say only allow it to run once, because if we run it again, we've got some store saying counter is already one, and if it's one, you can't run me again. All bundled onto the function. But it all starts with us returning a function from another function.