JavaScript: The Hard Parts, v2

Closure Technical Definition & Review

Will Sentance

Will Sentance

JavaScript: The Hard Parts, v2

Check out a free preview of the full JavaScript: The Hard Parts, v2 course

The "Closure Technical Definition & Review" Lesson is part of the full, JavaScript: The Hard Parts, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Will discusses the concept of lexical or static scope as the key as to why closure works, and defines in technical terms what is occuring when closure is used. A clarification is also taken regarding reassigning variables with the backpack attached.


Transcript from the "Closure Technical Definition & Review" Lesson

>> Will Sentance: All right, so let's talk about what this backpack is called, because I think we can all agree. This is an ever by the way, things have changed since we won. This lady's name backpack has been blowing up somebody's got me a T shirt with a backpack on the back of it.

I count that as constituting blowing up huge. There is one t shirt, exactly. But also, there is now a blog post the most popular blog posts on closure. Outlet written by the Guardian and New York Times. Engineering manager New York Times you came to hard part's, cool. I never understood closure until I thought about this way, learnt about this way, in which he referred to the backpack, 14 times.

Yeah, exactly, wow, 14/15 millimeter wide, exactly. That's how real is becoming. We're lobbying the spec makers.
>> Speaker 2: [LAUGH]
>> Will Sentance: And obviously not but I don't think any of you heard of, and certainly another heard of it, but there is a fancy name for it. There is a colloquial name used by developers for it.

I just don't love the reason being is I think it's vague and imprecise. It refers to both of the overall concept, and they call the backpack this as well. So these are, let me put that better. They refer to the thing that results in the backpack existing and they call the backpack all this same umbrella term.

I think that is a bit vague and confusing. So I'm gonna give us some fancy names for the backpack and then why we have the backpack. So first name, well I already told you earlier on that people pool their local memory sometimes the variable environment. As a brilliant I think developer out there who's a wonderful book actually which I highly recommend for friends known as like a smart but isn't like a book like let me take notes.

This is called If Hemingway Wrote Javascript. Yeah, I think it's a perfect gift book, I bought ten copies actually. It doesn't suggest much about the- anyway, I got them for Code Smith people, I think, it's gotta be the worst Christmas gift ever, right, you're getting a copy of When Hemingway Wrote.

So if I read, Hemingway wrote JavaScript by Gaga Angus Crow, a big fan of it, he calls this is basically he takes little snippets of code like Fibonacci sequence and writes them in the site in the style of famous writers. So Hemingway's is very terse, Nabokov's I don't know, I didn't read it, but I don't know what to say.

But so,
>> Will Sentance: He calls this backpack, he calls it the closed over. That is to say we close a lid on this data here, closed over variable environment. That is to say, we take the variable environment, kinda close a lid on it, and pull it out. Okay, so he calls it the curve, closed over variable environment code, not a bad name for it.

I guess I like it, now here's a name I quite like for it. I think this is the one that I said if you can say you're guaranteed a senior developer job. I have to take that back obviously. So hear the name, that it is nice, it shows a depth to understanding.

So this data here is persistent. Right, it sticks around, it's not like the regular data that gets deleted, it's persistent. It's data, okay, d for data. It's referenced, it's linked referenced by a scope property, okay. What is scope? Scope is the rules in any programming language. For at any given line of code, what data do I have available to me?

So if I'm in this line every day as this is it, if I'm in this line, somehow I have access to this data, and this data. Scope is the fancy word for what data and what are the rules for but we assume that if I run a function like outer.

in global that if we don't find data inside out to be connected to global, why? That's not like inherent in a programming language that was decided by the developer of the language, when they're deciding the rules of scope for that given language. The rules of what data is available to me at any given line in my running of my code.

You can imagine a language says no new data available inside that function, that's it. Beep every regional language and the scoping rule would be protecting the data only inside the function itself. You don't have access to that functions data. That would be that language is scope rule. This the language of JavaScript has a very particular scope rule.

Its scope rule is. What's called lexical or static scoping. That is to say that where I save my function determines for the rest of that life, for the life of that function. Whenever it gets run under whatever new label it gets, what data it will have access to when that function runs.

Is not where I run it. That would be called dynamic scoping. It changes depending on where I run the function. If I were to dynamically scope language, I'd run my new functioning and I'd look straight down to global, wouldn't find counter that was it. JavaScript is a static or lexically scoped language.

Lexical means the physical positioning on the page. I physically position this inside the running of outer. Is a lexical statically scope language. That means that even if I returned my function out, and theoretically all this data should have been deleted. Nope, because I have this fundamental rule of lexically scoped language.

I'm gonna have to grab all that data behind the scenes and put it out on the backpack. Such that when I run the function, I still have all the data from when I last scope. Not because I go back into the earlier execution context, uh-uh. I'm going back up into outer.

I didn't have to, I pulled the data from when the function incrementCounter was born out with me on my lexical scope property. Behind the scenes I pulled the data out and left it attached to now my new function. It's a lexically scoped language. Persistent lexically or static scope reference data.

So special type of scope, the lexical scope, with static scoping rule which means we literally bring the data with us from when the function was born. Because our rule is where my function was saved determines what data I have access to, when it's eventually run, wherever that may be.

And there it is persistent lexical static scope reference data. And you can see that's why I call it the back pack, look at that beautiful name.
>> Will Sentance: But in industry they tend to use the colloquial term that Kayla gave us earlier. Which is they say, put the data in the function's closure.

My problem with that term is a cool the overall concept, the notion of lexical scoping and they call that closure and then they call the backpack closure. It's the backpack as a result of JavaScript being a lexically scoped language, one that brings the data with the function wherever that function goes, hidden on the scope property, hidden on the backpack.

Meaning that if you save a function inside the room another function. When it exits, that should all be deleted, nope. But bringing that data with us on the backpack so when we run that function, it still has access to that persistent data from its backpack. There we go people, we're not quite done yet.

[SOUND] Let's do thumbs at that point in case this is raise any new questions. You lost me clear clarification, no looking around. Todd, I saw you looking around. Is okay good clarifications. Peter has one. Peter, go ahead please.
>> Peter: If you defined a new variable that you defined as my new function, would it also get its backpack?

>> Will Sentance: Okay, so there is a couple of interesting bonus things we can say around that. So you're saying if we said let's say Peter = my new Function, is that what you're saying? Yeah, so that would just be peter is now a new label for this same function with the same backpack.

>> Peter: It still gets access to all the-
>> Will Sentance: Yeah, absolutely. Cuz that's just now peter is a new label for this same function with all the stuff attached to it. This is literally attached to the function. myNewFunction is the label for all of this together now. Function code to run, I mean, just think about this.

It's labeled for a function code to run that can create, so memory. But it's also got its own permanent memory attached to it. That is kind of extraordinary. Yeah. There's one other thing I do want to add actually, keep it short. But, if I returned out from the same outer execution, free functions.

Which by the way, if you need to return that one things, how can I return out three functions from a student contracts? Yeah, Dan.
>> Dan: In array of array of functions.
>> Will Sentance: Array of function or object for the methods yeah, they would all be linking to the same backpack.

And so they'd all have access to that share backpack. That's kind of cool. But that's not where we're going yet. I thought we were going to raise Peter is this final piece here. So we saw all this here. What I call the backpack close over variable environment persistent lexically, scoped or standard eastcote, reference data, cache, backpack or closure.

The backpack or closure of live data is attached to increment counter via the hidden property known as scope. Which persists, even when this inner function is returned out. We grab all that data with us and pull it out, on the back of the function. So as we we use that function by its new label, we still have access to all that data.

And it's permanent. It ain't going away.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now