This course contains good reference material, but does not reflect our current quality standards.
Transcript from the "Closure Q&A" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Kyle: 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. So there should be no expectation of this is your first time to see it. No expectation that it immediately just clicks, it takes a while.
[00:00:19] 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.
[00:00:42] 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 because 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.
[00:01:00] 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.
[00:01:17] The first time you're doing it you're having to remember like hey how's it able to access that name cuz 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 Enclosures book and I cover it in extreme detail exactly how it works.
[00:01:37]
>> Speaker 2: Is the reason you call it closure because that stuff is closed to the outside world? Is that why you call it that?
>> Kyle: 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 side note, what it is said is this function speak because it accesses the variable name outside of itself.
[00:02:01] 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. [LAUGH] So I not gonna teach you Lambda calculus but that's the etymology actually goes all the way back to the concept of lambda calculus.
[00:02:21] 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.
[00:02:41] You gotta wrap your brain around it, you gotta try it few times.
>> Speaker 2: Are we doing this because like in other languages you can specify things as private? And here you can't because you can kind of move stuff, but now with this technique it keeps you from doing that?
[00:02:52]
>> Kyle: It is true that JavaScript does not have a notion of private, other than using this idea of they are each step inside of the scope. Supporting stuff inside of the function keeps it private. And there's a design principle in software engineering called the principle of least privilege or the principle of least exposure.
[00:03:10] And that design principle says keep everything private by default and expose only the minimal necessary to get the job done, rather than making everything always available. So here what we're saying is there would be definitely chances for me to have to expose both of these. But I could have a dozen other inner functions that I don't want you to have access to, their implementation details, their private things.
[00:03:34] If I don't expose it on the public API, it's not available. So it does give us the mechanics of private scoping.
>> Speaker 3: So rather than creating a function first name you could just return name, right?
>> Kyle: So the problem is this, instead of having a function name here, if I just said name, call, and name.
[00:03:57] Because this name is a primitive value, it's just a string, if anything was allowed to change that later on, if I had another thing like changeName,
>> Kyle: and that did this. And that change name was a method that somebody could call outside.
>> Speaker 4: Are you trying something different?
[00:04:25]
>> Kyle: If I said o.changeName("Marc") and then I asked what is an o.name, you would think that it would be Marc but it's here'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.
[00:04:51] So that's the reason why you would want to use a what's in programming terms it's 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 a detail, but that's the main reason why I would have something called a first name accessor method rather than the property itself.
[00:05:14] If it was never gonna change, then there's no reason why you wouldn't just show it. So it would be okay here we were never gonna let you change it,
>> Kyle: Yeah?
>> Speaker 5: So we have a few of them that you started using those closer to get harder to test functions as you can access them.
[00:05:34]
>> Kyle: 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, in the other teachings but let me just give you a quick glance at that topic.
[00:05:55] It is true that if you hide something inside of this functions, if I had ten 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 all people test stuff, some people think that unit testing means everything has to be tested.
[00:06:17] 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, pass some stuff in and have it sort of magically access stuff or whatever.
[00:06:43] It's like trying to do contortions while playing the game Twister. Like they wanna have access to it and they don't. So they make this backdoor that they get access to it 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.
[00:07:05] Which is that a unit is not just any function that I wanna test. A unit is the smallest indivisible piece of code that is used the way I'm gonna use it in my real application. So let's imagine a module that has 100 inner functions and just one public API method.
[00:07:25]
>> Kyle: 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.
[00:07:51] 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 the black box methodology test from the outside in rather than the inside out.
[00:08:12] That's a 50,000 foot view of a really, really long complex conversation that hopefully at least gets a couple of answers to that question. Let's scroll back up and see in this other questions if I missed other questions.
>> Speaker 5: I think a lot of people are asking for a real world example of using the stuff.
[00:08:33]
>> Kyle: So modules are the answer to that question, everything that we design is a module. Let's imagine you are designing a login page for your application. And there's an object that references the user and it has internal properties like their username and their password and their user ID and stuff.
[00:08:52] And on the outside, you have a public API, like is user logged in and it just tells you true or false, if they're logged in or not, that's a module. We got some private stuff we got some public stuff we got methods that we can call we got inner data, that's a module.
[00:09:08] So basically, anywhere that you would create anything even remotely conceptual like that, the most natural way to do that in JavaScript is with a module.
>> Speaker 6: So, can you relate it to something like a class, in the case of an object-oriented word?
>> Kyle: I taught an entire class on the topic of why classes in JavaScript are not correct.
[00:09:32] So I can't possibly answer that question to its fullness either. I hate to keep saying this but I got a whole book on it. [LAUGH] So I would recommend reading the this and object prototypes book to get a fuller answer to that question. But when you define classes in a language like JavaScript, you don't have any notion of encapsulation your privacy.
[00:09:56] The way classes are done in JavaScript everything's public, everything is accessible. And modules have true encapsulation with true privacy. So if privacy matters the module is the much more natural design.
>> Speaker 7: I just want to point out, you already mentioned this book, the Eloquent JavaScript book talks about this in such beautiful language.
[00:10:15]
>> Kyle: Yes, it does, it's absolutely true. I recommended earlier, I would repeat that, Eloquent JavaScript a great book to read. It is a companion to the stuff we're talking about. Okay, let's go back here.
>> Kyle: What kind of applications you have, I hope I've answered that now basically everything.
[00:10:38] He has some questions about does this come from list. Yes closures, it's a topic in lambda calculus that it's first showed up in computer programming in the list programming family.
>> Kyle: So to clarify return of the object, yes this object right here that I'm returning from line 7 through 10 that object itself represents the public API, of which there are two properties.
[00:11:16] 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.
>> Kyle: When you say private, you just mean not accessible, right, or do you mean not visible? Great question, not a dumb question at all.
[00:11:37] Private means accessible while running the program. It does not mean invisible to prying eyes when they do a view source. There is no such thing is that in JavaScript, all code that runs in a browser can be seen by a user. But what we mean by private versus public is what's accessible from any given location in your program can I access stuff.
[00:12:03]
>> Kyle: Okay, now I know especially given some of the questions, I know that modules are already starting to push the envelope for some of you and that's totally okay. The rest of what we're going to talk about today, this was the main thing I wanted to kind of go on.
[00:12:17] So we're going to take about a ten 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 for me, it's a full exercise with lots of different tasks and subtasks in it.
[00:12:32] And you're gonna go little by little by little building yourself up. And along the way, you're gonna get some practice with this concept of how to do something with the module. And I'll hold your hand through it, but this, we're gonna apply all of this theory. So we've got the theory out of the way, hopefully.
[00:12:47] And now we're gonna do the rest of the training, we're gonna spend kind of applying that to an exercise. So if that if you're already feeling a little bit like what's going on. It's okay we'll go through it together, we'll talk through everything. But I do encourage you, especially if you already got some experience with this, try your hand at the exercises even if it's confusing.
[00:13:06] There's value in the confusion. I know that's an 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.