Transcript

ES2015 Modules are a great way to share and organize your code. Let’s take a look at how we did it before ES2015 Modules.

Here we can see an HTML file. We’re reloading different scripts in order, and notice at these scripts there are very vigorous warnings to not change the ordering, and then notes on what needs to come first and what needs to come next. This is because there’s lots of things that rely on each other. We’re throwing stuff into the global namespace, we’re hoping nothing overwrites it, we’re hoping that the good stuff gets loaded first that we need to use. And this may be okay with one person on a small project, but it ends up getting chaotic.

With ES2015 Modules, it’s much clearer, much more explicit. Rather than have ember on the global namespace, we can import Ember from 'ember' . What that does is it takes the Ember module and it grabs something from it and calls it ember. We could call this something else. We could call this tacos ember, but it’s still grabbing the same thing. So we import things from the module system. We can also export them to the module system. So here, export default is saying, here we’re going to give you this Ember.Object , whatever is right after the export default , and then if you ask for something without specifying from this file, then we'll give you this. Here’s how we’re consuming this export . So here we have import Taco from your app’s name /models/taco . Notice the file path here. Ember’s file system is set up so it works with ES2015 Modules automatically. So we’re consuming the taco model, and then we’re using that in Ember and creating a new component which can then can be consumed by other things.

But there’s more ways to export something than just the default. Let’s take a look at our Salsa utility. So we’re importing the Salsa model, and then we’re creating three different types of Salsa, and then we’re exporting all of them, but exporting roja is the default. Let’s see how we would consume this.

So here we can of course still get the default, and the default is going to be roja . Once again, we don’t have to call this roja . We can call it anything we want because it’s our default. We could also import all three of them, and we do that by doing the curly braces on the side. These do have to be named correctly, so we couldn’t call it anything besides roja , anything besides verde , or anything besides doña . If we leave off this little tilde it won’t recognize what it is. And we can mix these as well. So we can get our default and import our other exports.

Oh, and I just realized a slight bug. Sorry if this has been confusing you. We either need to call the function here or remove the function apparatus here. We don’t need it. I would normally go back and fix this sort of thing, but slides.com has been crashing this deck, and so I don’t want to risk having to go back and try to load it again. This correction is also tangential to the main point, which is imports and exports.

So we saw that you can export the default, and then you can call that default whatever you want when you’re importing it. And then you can export other things, and you have to bring them in by their name, by the name you’re giving them right here. We also saw that ES2015 Modules system integrates with Ember’s file system, so that it’ll automatically create a module from any file based on what you export. I hope that helps you understand your code base a little bit better and teaches you maybe some new tricks. I’ll see you next week.