Since the topic of closure can be quite complex, Kyle spends a few minutes answering a number of audience questions. He also recommends some additional readings for those wanting a deeper understanding.
(flute and guitar music) - There's no question that the first time somebody shows you closure it bends your brain. The tenth time somebody shows you closure, it's still bending your brain. There should be no expectation if this is your first time to see it, no expectation that it immediately just clicks, it takes a while. But what I would say is, this probably comprises better than 95% of all code that I write, is in some way, shape, or form relying upon an understanding of closure.
So if... you're looking for the next place to go, once you feel like you have kind of a grasp on the mechanics of for loops and variables or whatever, the biggest conceptual thing that you could spend time trying to understand is closure. It's the most important. That's why it was the first book that I wrote in the series, 'cause I wanted everybody to know, if you're looking for the first thing that you should spend some time making sure you get, it's closure. Modules are how I design most of my software, a lot of people are like that.
They design software using this, this is what we call kind of the module pattern, and I don't have to think about how it works anymore, because closure is natural to me now that I've been doing it for years. The first time you're doing it, you're having to remember like: "hey, how's it able to access that name? "Oh, it's 'cause it's like inside "and it still has access, okay." And you progressively get more and more of your head around that. At some point, it will be appropriate for each one of you, to go read that Scope & Closures book, and I cover it in extreme detail exactly how it works.
- [Student] Is the reason you call it closures is because that stuff's closed to the outside world? Is that why you call it that? - It's not a name that I invented. It's a term that was invented long before I was born. The etymology of that word as applied to this concept is, that what it is said; this is just an academic sidenote; what it is said is this function speak, because it accesses the variable name outside of itself, it is said that speak closes over that variable. And that terminology actually comes from a branch of mathematics called lambda calculus.
Which I've never taken, and I don't even understand. (chuckles) Not going to teach you lambda calculus, but that's, the etymology actually goes all the way back to the concept of lambda calculus. As applied to programming, it's a super, super powerful mechanism. Maybe the most important thing that ever happened to programming. I know that sounds like a radical statement to be making, but it's really, really important. It just takes some effort, it's not like a for loop where I can just show you a for loop and you get it, you got to wrap your brain around it, you got to try it a few times.
Rather than making everything always available. So here what we're saying is, there would be definitely chances for me to expose both of these, but I could have a dozen other inner functions that I don't want you to have access to. They're implementation details, they're private things. If I don't expose it on the public API, it's not available. So it does give us the mechanics of private scoping. - [Student] So rather than creating the function firstName, you could just return name right? - So the problem is this, if I, instead of having a function name here, if I just said name: name, because this name is a primitive value, it's just a string; if anything was allowed to change that later on, like if I had another thing like changeName, and that did this, and that changeName was a method that somebody could call outside.
If I said o.changeName("Marc"); and then I asked what is an o.name? You would think that it would be Marc, but there's no such thing as pointers here, so when we made this it got sort of a copy of what it was at the time, so this would still print out Kyle. So that's the reason why you would want to use what, in programming terms is called an accessor method.
It's a function that I call to get some value out, rather than the value itself. Kind of a getting into the weeds sort of detail, but that's the main reason why I would have something called a first name accessor method, rather than the property itself. If it was never going to change, then there's no reason why you wouldn't just show it. It would be okay here if we were never going to let you change it. Yeah. - [Student] So I think we have a few back here, starting at the, if you use closure doesn't it get harder to test your functions? As you can't access them? - That's a good question, and there's a really long and complicated way for me to answer that question.
But I don't want us to get too far off track, so I will suggest, first of all I've addressed that in the books and the other teachings, but let me just give you a quick glance at that topic. It is true that if you hide something inside of this function; if I had 10 other functions here that were not exposed to the outside world, they're not exposed and therefore they're not testable. Some people think that the term unit testing, that's the most common term for how people test stuff; some people think that unit testing means everything has to be tested.
And for them, module design is kind of a negative because it looks like there's a bunch of stuff that I can't test. And there have been new patterns and techniques that have been invented to try to deal with that problem. The most notable of which is called dependency injection. Where I can do this sort of weird like: pass some stuff in and have it sort of magically access stuff or whatever; it's like trying to do contortions while playing the game Twister. Like they want to have access to it and they don't, so they make this back door that they get access to, or whatever.
I think that's, my personal opinion; all that stuff is nonsense. There is absolutely no point to any of those contortions. Because I define unit testing in a much more reasonable fashion in my opinion, which is that a unit is not just any function that I want to test, a unit is the smallest indivisible piece of code that is used the way I'm going to use it in my real application. So let's imagine a module that has 100 inner functions, and just one public API method.
In my definition the unit test only tests the one public API, and all the internal stuff is intentionally untested implementation detail. You're not supposed to test implementation detail. That's supposed to let you abstract the implementation details and refactor, and not have it break all your tests. So my definition comes from the outside, rather than from the inside. And there's a term for that by the way, the term is whether you prefer what's called black-box testing, which is: I test from the outside having no knowledge of the inside; versus white-box testing, which is: I test having full knowledge of the inside.
So my preference, when I do unit tests, is to test with a black-box methodology. Test from the outside in, rather than the inside out. That's a 50,000 foot view of a really, really long complex conversation. Hopefully it at least gets, gets a couple of answers to that question. Let's scroll back up and see if I missed other questions. - [Student] I think a lot of people are asking for a real-world example, of using this stuff. - So modules are the answer to that question.
Okay, let's go back here. What kind of applications, I hope I've answered that now, basically everything. You asked some questions about does this come from Lisp. Yes. Closure is... It's a topic in lambda calculus that it first showed up in computer programming in the Lisp programming family.
So to clarify return of the object, yes this object right here from, that I'm returning from line 7 through 10. That object itself represents the public API, of which there are two properties: one of them is a method and one of them here is just a string value property. But that is the public API for our module. When you say private, you just mean not accessible right? Or do you mean not visible? Ah, great question.
The rest of what we're going to talk about today, this was the main thing I wanted to kind of go on, so we're going to take about a 10 minute break now, to let some of that seep in, I'll answer if there are any more questions. But the whole rest of our course, is no lecture from me, it's a four exercises with lots of different tasks and sub-tasks in it. And you're going to go little by little by little, building yourself up, and along the way you're going to get some practice with this concept of how to do something with a module. And I'll hold your hand through it, but we're going to apply all of this theory.
We've got the theory out of the way hopefully, and now we're going to do the rest of the training, we're going to spend kind of applying that to an exercise. If you're already feelin' a little bit like "oh, what's goin' on", it's okay. We'll go through it together, we'll talk through everything. But I do encourage you, especially if you've already got some experience with this, try your hand at the exercises, even if it's confusing. There's value in the confusion. I know that's a, that's a unusual statement for a teacher to make, but there's actually value in the confusion. There's value in trying something without fully understanding it, and then layering on your understanding, instead of never trying it, because you don't fully understand it yet.
Note: This course was created on 03/29/2016 by Frontend Masters. We are pleased to host this content in our library.
- Carousels, panes, and modules
- Middle-end architecture
- Secure phrase generator
- Routing functions
- Calling the API
- Rendering on the page
- Shared data validation