Practical Applications

[00:00:00]
>> Will Sentance: Closure functions getting backpacks give our functions persistent memories. Look at this, my new function has a persistent store of data attached to it permanent. It sticks around, it's not going anywhere, a cache, permanent store of data gives entirely new toolkit for writing professional code. So firstly helper functions, you see them in the challenges, everyday professional helper functions, like once and memoize.

[00:00:27]
Let's actually take a second to look at these. So once and memoize, here would be an example. Maybe I can use red, let's see. So if I were to do a onceified version of multiply by two, the first time I run it multiply by two with the input of seven.

[00:00:47]
It would give me out 14. Next time I run it, with the input of ten it would give out sorry, or something like that, you can't run me again. Because when I ran it, I would have created it inside the runner running another function returned out. And I throw it back over the counter.

[00:01:09]
When I run it I've written the logic that it does the multiplication, but then it increments accounts in the backpack. Next time I run it, it checks that backpack. Count is already one. And instead of even doing the math returns out sorry. It might typically instead to do this it might actually typically store the value of 14 and about pack.

[00:01:28]
And next time, it's gonna return on that original value. This is super useful in practice. Obviously not desperate for this one, but super useful in practice. If you're building any App where you want to lock down maybe for example like a winning function, that when the apps finish the game is finished.

[00:01:44]
And you want you don't want to have someone, rerun that function, you want to lock that function down it can only be run once it's the winning function. It's a function that when the when somebody won the game triggers all the all the stuff to do on winning or not. Tic tac toe, for example.

[00:01:57]
You don't wanna be able to reset any of the values in the cells. Once it's got an o, it's locked down, you can't run it again. Once it finds a really clean and readable way of locking down code to not run it multiple times, that's kinda nice. ization, standard computer science practice, of saying, if I have a task like, that's starting to become my [LAUGH] too much information here. If I had a task like finding the nth prime number.

[00:02:27]
Any slow task. The nth prime number that's fine suppose like 127,000. Okay, clearly my random number generation is not very good. I've got one of the least random numbers in coding 127,000. And one, if I try to find that prime number, the 127,000th prime number, that's gonna take a bit of time.

[00:02:49]
But in my run time, in my app, if I run it once, it may happen again. I'm not turning my app off and starting it again very often. So if I run it once, I may need to run it again, typically. Do I wanna recalculate that? Or do I want to have that nth prime function definition have a backpack into which I have an object with key and value pairs where every time I run it with an input, first time I run it with an input, I do the hard work, figure out.

[00:03:16]
I don't know, maybe the nth prime number, maybe the 127,000th or first prime numbers I don't know, whatever it is. And then, in my key value pairs in the backpack of the function, I'm going to have a key 127, 001 and a value of whatever that prime number is.

[00:03:31]
The 127,000 1st prime number, maybe it's I don't know. That's good. Maybe get 257,133. There you go, high risk there. It is installing that. Next time I run the function, nth prime, that either shows I have no idea about prime numbers or. Next time I write the function with that with that inputs.

[00:03:54]
I ain't gonna figure it out myself from scratch again. I'm going to go look in the backpack. Check it's been done with, oh it's there? And with one step, one look up, grab and return, super nice. This is the notion of memoization, giving our functions persistent memories of their previous input output combinations.

[00:04:15]
And that's super effective. But there's more iterators and generators. What's it say? Which use lexical scoping and closure to achieve the most contemporary pattern. It's a very empty statement. They are something in hard parts, new hard parts. You ever seen it? I think this is a very elegant way of accessing data.

[00:04:34]
So we saw early the full loop is a pain in the ass. I don't really care about the index, I care about the value in that position of the array, the element. Well, it wouldn't be amazing if I could create a function that when run, it gives me out the first element in my array?

[00:04:48]
Run it again, its output is the next element, run it again its output is the next, how's it remembering previously given out previous elements? Don't worry, in the backpack its storing a little counter that's tracking through the underlying data. Generating say that's an even larger level. What if I could actually appear to pause the running of a function?

[00:05:09]
Or what is the running of a function? Well, its memory and the line you're in in the function. That's it, if I were to come back to a function, all I need is what was in the memory. And what line was I on a generation, it says you come back to continue running a function, how?

[00:05:21]
Because it stored all the live data. In the backpack, meaning when you come back and start running it again. It just grabs a day from the backpack and there is all your data is you went and you are back in the function. Module pattern, right? This is really interesting.

[00:05:36]
We want to have data that persists for the lifespan of application. Where can we normally puts it? We can not put it inside a function call because he gets deleted. Once you exit the function, he put it in global. But in a lot of code base with that 100,000 lines of code with 100 view rappers.

[00:05:52]
You ain't having global memory polluted with the global label results as a lot of developing your team who love that label. And you know declaring with Khan's help somewhat but just now no one else can declare it globally. I think that much better. So instead we have design patterns that preserved state that's live data for the life of your application without polluting the global namespace, multiple patterns.

[00:06:15]
One of them is many of them. If he's achieved the same thing, what are they doing? What's the model patent doing? You know what it's doing, is protecting state inside backpacks. It saying there is a way of maintaining state for the life of application. And that's by the magic, or not magic at all.

[00:06:31]
That's by having data that is protected, can be interfaced with, but only through a very, very clean interface of running that function. And making sure you pass in the right stuff, to get access, and store and persist data in the backpack. And the node module pattern is all just using closure In the backpack.

[00:06:50]
And you see this JavaScript. We'll see to it tomorrow, call-backs and promises also all rely on closure if it's this state. What this means is in a sync job, which we'll see tomorrow, you often send off a task that's gonna complete long in the future. When it does, you're going to run a function on that data.

[00:07:10]
And you may want to use data that was there when that function was initially set up and the toss was initially set up. But hold on, that day's all gone, hasn't it? Nope, that data that could ever be used is held on into the functions backpack. Meaning when we end up running the function, for example, we go and speak to Twitter, bring back send tweets, trigger a function to run automatically on those tweets.

[00:07:30]
Maybe it needs some data that was there when that function was initially defined and the speak to Twitter task was set up, but it that data still there? Well, of course it is. Don't worry, cuz it's stored in the backpack.