This course has been updated! We now recommend you take the Angular 9 Fundamentals course.
Transcript from the "Using Dependencies" Lesson
>> Scott: As I'm going through this page right here. You see anything that has like a yellow or orange or amber, whatever color that is, background. This is like a ES 2015 feature. So the rest of them are like bluish gray. But the yellow ones are like, this is something to do with the ES2015 specifically.
[00:00:19] So we're going to talk about now is I think the most important awesome feature in ES2015 and that's the ES2015 module system. So this is important is going to touch a little bit is very complex and we already have another course in front of masses that talks more in depth about it or don't talk about a little bit in the context of how we're going to use.
>> Scott: So like I said, Webpack allows us to use common js in a browser. So that means we can use node modules and npm for our browser related dependencies. Which is, in my opinion really great cuz npm is one of the best package managers out there.
[00:00:56] So just like node, we can use the require just like we did here in our go file right? We are able to use this require here, which is a synchronous method which will go find another job, a script package and give us access to it here. Right, we can do that in a browser now, we can totally do that.
[00:01:14] So, if I wanted to, I can go into app JS, and I can say, yeah let's just var. You know thing = require, something. So that's going to look in no models folder for thing. Obviously it's gonna throw out an error because there's no such thing as thing, but it would work if it did exist and you do the same thing with browser fire as well.
[00:01:35] So nothing new there. This has been around for quite some time so webpage will do that. Webpack will do that, that's great and all but were using ES2015. So we don't want to use the actual require syntax all of the functionality will be the same because the thing that's compiling is webpack, JSPM does a little differently.
[00:02:00] But because we're using the web it's going to be common JS. So we can use require but as you say doesn't fit into this look at the new module feature. So what we're going to using instead is this import keyword. So if you various Python or Java, you have this import.
[00:02:16] This is what we're going to be using. So normally what you would do is you would say something like var_ = require [INAUDIBLE]. Well what we can do it says we're going to import I just this low dash from a dash, it's the same thing if if this were actually compiled down to this and we could check it out.
[00:02:35] Let's look at it. So if I go to right here and I say import_from_loadsh.
>> Scott: And I save it, it should have run again. I go look in ban on that JS.
>> Scott: As you can see, it does something like that. So it's doing the shimming of requiring, but basically it's requiring the load dash right here, that's what's happening.
[00:03:05] This is just webpack shim of CommonJs. But it's really compiling down to just doing require. Webpack require is the same thing as require.
>> Speaker 2: You spelled low dash Ron, I think
>> Scott: Yeah I did spell it wrong, I knew it was going to throw an error. I just wanted to show you what it compiles on to, thank you.
[00:03:23] Really horrible spelling. So it's so that's all that's going to patent is this is what we're going to be using in a browser import so little different but you'll see that it's very powerful. So using that import and from key words we can access other modules. So above is just an example of how we access like a node module just like we did with require js but how will we access the models that we create because if you take a look.
[00:03:51] If you think about it because I'll change that, oops my god. Because these note modules are actually written ES2005. So that's annoying because nobody's already ES2005, or I'm sorry. ES5. They don't have the actual use doesn't it syntax as far as exporting them right. They're using module on exports.
[00:04:18] All right, so when we import them, we can import them with any variable name that we want. I can say import whatever from lodash and it will still work. It doesn't doesn't matter what variable name I give this package because it will just export as a common js, but when we go to import our code, we can't just call it whatever we want.
[00:04:37] Because our code is actually written in ES2015 and it's gonna be the export a very specific way and we have to import a very specific ways. So there's a slight difference in how we're gonna handle that. We can choose to say if we wanna import our modules with whatever variable they want.
[00:04:52] We have to specify that I don't export by default it is not there. So I'll saw you what that means in a little bit. So like I was saying the naming of the variable is dependent on how it was exported so uncommon JS because it's ES5. Everything's export it with a default keyword.
[00:05:13] So we can import is where we want. But things to remember though also, in common JS when we want to import a file, just like we did in our Gulf file, we import this webpack. We had to put the dot forward slash in front of it. If you don't do that in common JS, it's gonna think you want something in a nodes module folder.
[00:05:32] Right, so if you don't put ./ in front of it, it's like you want node module/ webpack config and it's not going to be there so it's going to throw an error. But put ./ in front of it, it's like you want your file. That's called this got it.
[00:05:45] So remember that, and the path is going to be relative to the file that you're importing requiring from. So with that in mind, here are some examples of different patters use in import and export that we are going to be using for there for the duration of the course.
[00:06:01] So like I said, importing as any variable name, you must export it as default. So, if I want to be able to do this in app.js import config from my config file, and just like comma js I don't have to put the extension, I don't have to put dot js.
[00:06:31] By putting the default keyword on it, I'm telling whoever imports this, it's just like calling When you do like, module.exports and you just export one module for the files like the same thing. But it also tells you that the file that's importing it. That you can name it whatever you want.
[00:06:49] So I don't have to call this config anymore. I can call this whatever because I export it as a default. So that means, doesn't matter what the name was in this file. I get import as whatever I want up here. That's what that means. So it's like common JS.
[00:07:01] So that this is, yes.
>> Speaker 3: So since it's default does that mean that in part you don't have to specify anything it will just be available as what you defaulted it as. So in this case you an app J.S. in the import statement you can remove the face of import from Slash config and then you config JS, or and then you could use it in there as what has been exported by default.
>> Scott: I don't think that's gonna work. I could be wrong but, pretty sure that's not gonna work. You'll probably get an error from Babel when it tries to compile. When it sees import and from, I think It's expecting to import it into something.
>> Speaker 3: It won't take the default export name.
>> Scott: Right, because default means I don't care about the name.
>> Speaker 3: Right.
>> Scott: If we got rid of the default, then I can see that maybe but if you put the default there it means like I don't care about the name you still have to give it a name because it doesn't know what it won't know what to call it if the default was there.
>> Speaker 3: Right. Okay, right.
>> Scott: Yes.
>> Speaker 3: So like when you're importing a node module that you created and in creating you define that as a variable all of it so that you have like method config.something or whatever. Usually you would you do like to require exactly what equals what exactly want to see with that config and then I can reference.
>> Scott: The properties on it
>> Speaker 3: Is that the same thing?
>> Scott: Yes the same thing. So if you want to do that like. So if it was an object then yeah you can just import this config and then down here you can write config setup config out whatever else wherever you exports the same thing.
[00:08:38] Yeah it'll totally be the same thing. So that's one approach. The other approach we'll get to in a minute is how to through export and import many modules from one file.
>> Speaker 3: Sure.
>> Scott: So we'll see that in a minute. So here is another pattern. So above is just like I just want to import as any variable name as a default.
[00:08:58] The pattern below it is like now I wanna strictly keep the naming of these modules. Right, so, if I wanna export it as this name, and I want to be able to import it, in fact, you have to import it with the exact same name. So, the way this works is in app.js, I would say, import, and I use these brackets.
[00:09:17] So, it's not an object literal, it looks like an object literal, but I think they just ran out of characters. There's not enough characters, so they had to use the same thing. You're going to see these brackets in like ten different features and you see the other and it is kinda annoying, but they use it everywhere.
[00:09:30] In fact you'll see the exact same thing a one line and then a line below it something really different the exact same thing you'll see places like this is crazy. So by saying import bracket configuration bracket that means I'm expecting there to be. Something like this in the appropriate file.
[00:09:47] So we can we can say export the variable config equals whatever it was you go in this case is an object. So that means we can also export an assignment expression because in this same line, I'm assigning config to a value and I'm exporting that expression. So that's really cool I can export that expression.
[00:10:06] Or at the bottom of the file, if configure is already defined I can just say export the brackets config, just like I imported it. So either way, it would allow me to import it like this.
>> Scott: Right, so exporting it with the same brackets and importing it with the same brackets works.
[00:10:23] Or just placing the export keyword in front of the function or I'm sorry front of the variable assignment will also work. So this is the way you probably see, this is the way that most of the code that we're going to write is going to look. So like this strict naming.
[00:10:39] So you get used to it. Yes.
>> Speaker 4: So config is like a variable right?
>> Scott: Yeah.
>> Speaker 4: And you said the brackets are assuming that the name is the same name that you're exporting, why would you want that? Why is that a good thing?
>> Scott: Yes, so let's say you have, well one reason you want that is so you have the same naming for the same thing across your application.
[00:11:03] If you did this up here loosely named. You know modules and we were importing config everywhere in our application. But in this file it is called config and this file is called setup and this file is called something else, right? It's like very confusing to figure out what's going on.
[00:11:18] Whereas if we do this, it's always going to be the exact same name. In fact it won't compile unless it is the same name. So this is a way for us to to keep that very very strict and I find it is better for organization.
>> Speaker 4: All right.
[00:11:31] That makes sense.