JS.Next: ES6 / ES2015

JS.Next: ES6 / ES2015 Module Programatic Loading API


This course has been updated! We now recommend you take the ES6: The Right Parts course.

Check out a free preview of the full JS.Next: ES6 / ES2015 course:
The "Module Programatic Loading API" Lesson is part of the full, JS.Next: ES6 / ES2015 course featured in this preview video. Here's what you'd learn in this lesson:

The Module Programatic Loading API uses promises to externally load modules. Developers can also catch any errors that may occur and handle them accordingly. Aaron demonstrates how this API can be used to load multiple modules and explores a few of the additional methods.

Get Unlimited Access Now

Transcript from the "Module Programatic Loading API" Lesson

>> [MUSIC]

>> Aaron Frost: So let me talk about the Programmatic Loading API real quick. This is what it looks like. So you say system.import, and you give it the path. And then it's gonna go ahead and return to you a promise. And when the promise comes back, it's gonna give you the module back, okay?

[00:00:23] So who here is not familiar with promises? Cuz this is promise in text here. This is .then. It basically makes async code cleaner but you're gonna call system.import and then you're gonna, when when it gets back, you're gonna just call .then and it won't execute this function here.

[00:00:40] Until it actually goes out, gets that file, brings it back in, evaluates it, and then it will give it to you. That make sense? So, and if there's an error, you can also catch the error as well, but this is what the import API looks like. It's based on promises, and the promises provide whatever was exported.

[00:00:59] You could use promises to load multiple at one time so you could be like hey, Promise.all. And then you could have just an array of file paths and you could do a map on it and say system.import each one, and each one of that map would return the promise.

[00:01:16] So you basically have an array of promises. And then you could put that inside of this promise.all, and call .then and it would give you back an array of modules, anyway. This is how you can programmatically use a loading API, okay? The loading API has multiple methods and some of them look redundant.

[00:01:37] System.import and system.module, they both return the module via an import. I don't know the diff to be honest with you. I mean the source is a string or a reference to the path. You can set one, if you created a module you can go ahead and set it, and then you can define one which will eval the code but not import it, I don't think, I'm not sure.

[00:02:01] I wish had better explanations though, yeah?
>> Speaker 2: I'm not sure if there's an answer for this yet but, there's a question on chat about, if one of the things you're trying to export, say it's a relative path one like the re-exporting. If it can't find that and import to export, does it throw?

>> Aaron Frost: Yeah, so I'm guessing that, so see this system right here, this System.import? And then it does a then, and a catch. Then is the success on the promise, and the catch is the error on the promise. I'm guessing you'd get a catch on that.
>> Speaker 2: But I think she's talking more like in the actual definition of a module, like if you went back and a few slides.

>> Aaron Frost: Back in the import export stuff?
>> Speaker 2: Yeah, like if you're trying to export from some other file and it can't find it-
>> Aaron Frost: Can't do it.
>> Speaker 2: Does it throw?
>> Aaron Frost: That's a good question. I would imagine that it throws.
>> Aaron Frost: Anyway, so this is the API, import, module, set, and define.

[00:02:59] Again I wish I had been able to mess around with this stuff and give you guys better explanations. There is something coming in the future which is a module tag, which will kind of take place of a script tag. And you'll just give it the path to the module that you want it to import, and you can kind of polyfill this thing by, there's a polyfill out there right now that will allow you to kinda get the same kind of functionality.

[00:03:29] So let's say we go to import jQuery from our lib/jquery. If you go ahead and log the dollar sign is in this, that basically tests to see if this has the jQuery object in it. And for us this is gonna be the window, right? Because we import it in a module it didn't actually put jQuery on the window.

[00:03:54] It kept it local. It's like localized to our module. So you know how normally, any time you import jQuery, it clobbers the window with a dollar sign no matter what? This thing would maintain it into your module. However, you can still talk to the window if you needed to and,

>> Aaron Frost: The module tag forces strict mode, so there's no pre-ES5 syntax in here. It's all forced you to use strict mode in here, so yeah.
>> Speaker 3: Does that allow for multiple jQuery libraries?
>> Aaron Frost: Probably, I hope so, but if you had two sections of code that depended on different ones, you can just make them separate modules and then it doesn't matter, right?

[00:04:41] You could just import them, import one in one module and import the other in another module, and they don't care about each other. Yeah?
>> Speaker 2: So with that module tag, how do you name the module? So you have a module tag, what if I want to use that module in a script tag then, what is its name or whatever?

>> Aaron Frost: That's a good question. I don't know. Can someone write that down and we'll look it up?
>> Aaron Frost: Yeah.