This course has been updated! We now recommend you take the Functional-Light JavaScript, v3 course.
Transcript from the "Closure" Lesson
[00:00:00]
>> [MUSIC]
[00:00:04]
>> Kyle: Let's now turn our attention to closure. We already sort of mentioned this several times, I wanted to give you a slightly more formal, but still very, very informal definition for Closure, okay? This maps somewhat, to another definition I've given this in another one of my workshops. But again, this is all about trying to boil this down to whatever basic takeaways we can get.
[00:00:28] So Closure is when a function "remembers" the variables around it even when that function is executed elsewhere. Outside of itself and then you take that function and you send it somewhere else, where it wouldn't normally have access to that variable. The fact that it still has access to that variable is closure.
[00:00:49] I'm not going to go to extreme depth, length to explain all of that. I wrote a whole book about scope and closure if you're interested in digging more into that topic. But we'll just illustrate in a very basic sense how closure is going to be something we're going to use or see being used in our functional programming.
[00:01:06] Okay, so here's an example, I have a function foo, and inside of it I have a variable called count. And then inside of that, I have another inner function, in this case it happens to get returned. So I'm returning a function back. We've already seen the returning function pattern before.
[00:01:22] So we're just seeing that again. But you'll notice that I have that count variable inside of the function and it's referencing a variable outside of it so. Strictly speaking that's scope but what's important here is that, that function gets transported outside of the function foo. And even when foo is finished, cuz foo finishes on line 9.
[00:01:41] And there's microseconds of time that happen between line 9 and line 11, 12, and 13. And we would normally think about the whole state of foo going away. That foo would finish and all of its internal state would just get garbage collected. But that doesn't happen in this case.
[00:01:57] And the reason it doesn't is because that inner function, has a closure over that variable count. Just by simply referencing it, it gets closure of it. And that means that that scope, that state, is going to be kept, it's going to be preserved. So we return that function back, we give it the name x on line 9, and then we call it multiple times.
[00:02:18] And you'll notice that we are actually, updating that variable every time. So we are getting out a new value each time. That's an extra size of closure. There are many, many other ways to think about closure. I'm sure you've seen them with your assigning click-handlers to function and referencing variables.
[00:02:36] Setting up timers, Ajax callbacks, hundreds of other examples. Here we see a closure because a function is remembering enable to access a variable that was around it, that is outside of it. Even though we take that function and transport it elsewhere. In this case returning it out. Now something interesting about this closure that I want to point out is that while this is closure.
[00:03:02] This is not strictly speaking what you're probably gonna see as a very common pattern in functional programming. Because every time I call x, I get a different answer. So there's an internal state that's happening, which means I still have to track that state over time. I have to understand how many times x has been called.
[00:03:23] It's not an external state. That's changing something where that state can be changed in an entirely different way. So it's not some free range variable like count hanging out on the outside. It's hidden within a closure but there's still side effects happening, in the strictly purest sense. So the way we're using this function have two very, very functional concepts being married together here.
[00:03:47] But the way we've married them together is not as functional. It's a bit impure that doesn't make it bad. I use this all the time and many of you use this in your programming but you should be aware. If you're trying to use a functional concept, this usage of closure is perhaps not as functional pure.
[00:04:09] Now how could we use closure in a more effective way as a functional programmer? Same principal will apply, closure is the same principal regardless of how you look at it but how we use it can be different. So in this case, I declare a function called sumX, it receives an x variable.
[00:04:28] You'll notice that I am closing over that x, just like I was in the previous slide. I am closing over that variable and I am returning that function. But what's the key difference here? The key difference is that x never changes. Does everybody see that? For the lifetime of my reference of that function, which I happen to call on line seven, I call it add ten.
[00:04:49] For the lifetime of that function, every single time I call it the x value is always going to be ten. Same principle, still closure, but here I'm not allowing it to make some side effecting change. Where I'm going to get a different answer every time, this is more functional.
[00:05:06] This is a technique for applying more functional programming idioms to our programs to make them more reasonable. So here I'm making a function, an incredibly useful function and another one you should add to your utility library, get rich and famous. I'm making the add ten function which takes anything that you add to it like the value three.
[00:05:28] And it adds it to the value ten that it's already saved in its state, saved in its closure. It turns out that sort of technique of creating something, sort of as a specialized thing that it doesn't have other stuff, this goes by fancier terms. So, bear with me for just a moment.
[00:05:46] It goes by currying or partial application, but taking a function that normally would need multiple variables and presetting some of those using closure. That's called currying or sometimes depending on how your'e using it. Whether its currying or partial application, they are kind of two sides of a rubik's cube if you will.
[00:06:06] So yeah, so there's some crazy complex terminology but let's not worry about currying and partial application. Let's just worry about this idea that a function can remember the variables that it has around it. And we can use that to our advantage to save some state along the function.
[00:06:20] The fact that, that state doesn't change over time is what makes this easier to reason about.