This course contains good reference material, but does not reflect our current quality standards.

Check out a free preview of the full Organizing JavaScript Functionality course:
The "Modules" Lesson is part of the full, Organizing JavaScript Functionality course featured in this preview video. Here's what you'd learn in this lesson:

Closure is crucial for creating modules. Modules let you define private implementation details that are invisible to the outside world. At the same time, you can create a public API to allow access to necessary functionality. Kyle shares an example of how closure is used to create a module and answers a few audience questions about how it compares to other languages.

Get Unlimited Access Now

Transcript from the "Modules" Lesson

>> [MUSIC]

>> Kyle: Okay so you may still be kind of like it's crazy and it's mind bending, what kind of weirdnesss are you creating here? I do expound upon this more in the chapter. But let me show you one other way and this is much more applicable to the coding that we're gonna be doing for the rest of today.

[00:00:19] One other way that we can use that closure trick to our advantage and it's called the module design. Module is perhaps the most important design pattern in all of JavaScript. It's certainly the most prolific design pattern. So again, remember the pattern that we wanna look for is having an outer function and an inner function, without fully understanding the mechanics of closure.

[00:00:44] If you just look for that pattern where one function sits inside of another, you'll know that's how closure ends up getting created, having one inside of the other. So if I wanted to be able to hide some details. I could have an outer function called Hello. And in here, it could take a name as its initial parameter.

[00:01:12] And inside of here I could have a function called speak that uses that name variable. So everybody see how that name variable is accessible to it? Because of the scoping thing, that I can always walk up and find it in a upper level. So that function speak, if I return function speak, this is exactly like we just saw with make outer, I'm returning a function back.

[00:01:44] And I know if I say fn = Hello("Kyle"), then and now I have a function that every time I call it, it's going to annoyingly say the name Kyle, all right. Super useful function, maybe the most useful function I've ever taught you, is a function that when you call it, all it does is it prints my name.

[00:02:09] That will probably be one of the cornerstone foundations of all of your JavaScript programming is that, okay. So, for those of you on line I'm joking obviously. Okay, so if I return a function that's great but what happens if I return something slightly more useful like an object.

[00:02:28] So, we know we saw earlier that blocks, when we have a pair of curly braces that looks like a block. When a curly brace pair is used in the place where you would normally expect a value, it's not a block, it's an object. And objects have properties and values on them.

[00:02:45] So, let me just do a side note here. If I said something like o = a curly brace pair, and I put a property on it like super, well let's not use super. Let's use awesome as my property name and the value is cool. So I have an object with one property on it and that property has the value string cool.

[00:03:09] That means later in my program I can say o.awesome and it will give me that value cool. So, it's a way to put property values or function methods on an object, okay.
>> Kyle: Isn't there a way to call speak from outside the hello function? So, let's back up.

[00:03:32] If all I do is return speak here,
>> Kyle: The only way to call that is to call it with fn. If I tried to say speak, would that work or would that not work?
>> Speaker 2: It's out of scope.
>> Kyle: It's out of scope. Does everyone see that this name is only available inside, it's not available outside, by the same rules of scoping.

[00:03:58] We can go in one direction, we can go upward, but we can't go downward into scope, okay? So I can't call speak here, but because I'm returning it, then I have access to be able to call it from the outside. So I can say fn. And that's what lets me annoyingly print out Kyle.

>> Kyle: But now if we consider instead of just passing back a single function. If we pass back an object like this, and on that object I have a property name called speak, as we see here. That is referencing this internal one, these names do not have to match, but let's just make them match for now.

[00:04:40] If this is what I return for my function, instead of getting this as a function, this is an object now. Does everybody see that? What I'm getting back is an object not a function, and now what I can say instead of saying o() cuz it's not a function, what I say is o.the property name speak.

>> Kyle: And to hammer that point home, if I gave it an entirely different name like say, then that's the name I could use on the outside.
>> Kyle: In other words, I have this internal function, which is only accessible inside of the hello function. And I have something on the outside that is accessible only as that external name, with whatever I end up calling it.

[00:05:36] Is everybody following that or am I losing people? What if you passed in an argument to say. We could definitely set this up to accept an argument in the news that I'm just keeping the example simple. But we could definitely set it up that I could pass in something, like if I called this last name.

[00:06:00] We could definitely use that.
>> Kyle: And that would print it out.
>> Kyle: See how that's exactly like the make outer that I was showing before? It remembers one variable from its closure and it gets another one passed in. Same thing as what make outer was doing. So what we're seeing here is that returning this object from a function call, is essentially creating what we in programming terms call a public API.

[00:06:37] The stuff that's on the inside, like this function, any variables that I might declare inside of there. All that stuff is completely private. We can't get at it from the outside world. But the stuff that we put in this object, and return it back, that is accessible to the outside world.

[00:06:55] Which is like a public API to access the internal module.
>> Speaker 2: Just some questions on what's better or why.
>> Kyle: Why would I return an object? An object won't let me have multiple methods on my API. So, if I had 15 inner functions and I wanted to expose 5 of them, I could list all 5 of them here and I'd have an API that had multiple public end points.

[00:07:26] So returning an object, lets me put multiple things here. If the speak was the only function that was necessary to expose, you could have of course just returned only the.
>> Speaker 3: So in other words, you could have the last one of the one of the properties. You could have lastName, and you could return lastName, or firstName, or whatever you find.

>> Kyle: If I said lastName here, what value would I assign to it?
>> Speaker 3: Probably, the last name that was passed in.
>> Kyle: You could conceivably want to assign off that lastName somewhere, but there's no way to access this object the way it's currently written to be able to do that.

[00:08:02] So a more realistic scenario is to suggest,
>> Kyle: That we might have a method called firstName,
>> Kyle: Which does nothing. It doesn't take anything,
>> Kyle: Except it returns back to the name that we initially passed in. So now, I have two different methods as we say on my public API.

[00:08:33] One of them is say which prints things out, the other one is firstName, which doesn't print anything out but it returns back that initial value that I passed in, the value Kyle. So, it's two different ways of defining these methods on my public API.