ES6 Module Syntax

[00:00:00]
>> Kyle Simpson: To bring modules into your syntax, to import them, there are two major styles of import. There's a bunch of variations, but two major styles of import. One is called the named import syntax which you see on line 1. I exported the default function, so technically its name is default from the outside, and then I decided to name that default import ask on line 1, which means now in my top level scope of where the import happened, I now have an identifier called ask, which is reference bound to the ask function inside of the module.

[00:00:38]
That's what we sort of referred to as the Java style of import where import means literally to import identifiers into your scope. The second style, as you see on line 7, is referred to generally as the namespace import, which is to say I wanna get this whole module and collect all of its contents onto a single name spaced variable, in this case called workshop.

[00:01:01]
>> Kyle Simpson: So I do import * as workshop, that's called the namespace import. And that's a different school of thinking, which is that modules are like these namespace things. I think that style represents the vast majority of how modules have been done in JavaScript for the last 20 years.

[00:01:19]
And the named import syntax represents kinda the new school of thinking. It's not that one is right and one is wrong, but they're different ways of thinking about how you consume stuff. I certainly am in the camp that prefers to import a namespace, and then I have a thing called workshop, and then I have another thing called something else.

[00:01:40]
That's the way my brain works, some people like the named imports, both syntaxes,thankfully. They weren't gonna do the name space import and then they added it at the last minute and I was so thankful because that's the way that I would prefer to deal with it. So there's your ES6 module syntax, such as it is, we're not expecting syntactic changes but there will be a variety of caveats when you're using it in node land.

[00:02:05]
And because it's gonna be so popular in node land, you can expect that those same caveats will probably carry over to your browser JavaScript, as well. You got a question.
>> Speaker 2: When you say you prefer the old module style you mean, the revealing module pattern in one file?

[00:02:21]
>> Kyle Simpson: The function wrapped around a couple slides ago.
>> Speaker 2: Thank you.
>> Kyle Simpson: Mm-hm.
>> Kyle Simpson: Specifically when I'm gonna do a module, I expose my modules as UMD style modules. That's the universal module definition. It's supposed to kind of inter-operate between browsers, module loaders and node. So that's the format I choose to write in.

[00:02:46]
>> Kyle Simpson: So whether you use a syntactic support in your language to define your modules, or whether you choose to hack it with the old school revealing module pattern, the same concept applies, which is that you're organizing a set of behavior into a cohesive unit hiding data in it and exposing a minimal necessary API.

[00:03:06]
That's the design pattern that you wanna get. And then, like I said, it’s one of the most important things that you can learn about organizing your JavaScript. It actually doesn’t matter what you do on the inside. You could write classes all over place on the inside if that’s how you really wanted to do stuff, but you're still gonna want to organize all of that behavior into a module, so that somebody can import that behavior into their app and use it.

[00:03:29]
Module pattern, is definitely here to stay, it's not gonna go anywhere. All right, so there you go, there is the module pattern. And with that, we now have a full breadth of understanding of the lexical scope core or the main pillar, this main pillar of the JavaScript language.

[00:03:54]
And if I were to boil down among the three pillars, this one is the most important. It's the one that touches everything else in such a foundational way. So hopefully that has provided you a better perspective on lexical skill.