Component-Based Architecture in AngularJS 1.x and ES6 Aliasing Dependencies

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Scott Moss: Any other questions on that?
>> Off Camera 1: You can alias those as well, right?
>> Scott Moss: Yes, so you can also alias these. So I'll show what that looks like. There we go. So if you wanted to alias these imports, what you could do is, by the way, this is the Babel.

[00:00:22] Try it out, you can come in here and just play with all types of ES2015 stuff. So you can come in here and you can say. Can you guys see that?
>> Off Camera 1: Mm-hm.
>> Scott Moss: Okay, so you can come in here and say, you can say, import, and let's use our same example, config, and then you can say as setup from config.

[00:00:41] And what that's gonna do is allow us to have this variable called setup. So if I were like, console.log setup, all right, it'll be a real thing. It's gonna error here, of course, but that's what that will do. So using the as keyword is like, load up this named thing inside of this file, but alias it as this guy inside of this file.

[00:01:03] That's what that means.
>> Off Camera 2: I wouldn't recommend, that, though, because like you said, the name consistency. Like, why would you, I have seen that before, but why would you ever do that?
>> Scott Moss: Good question. So we're going to use this, and the only way you would use this is if you were loading up.

[00:01:17] So you export it as a named thing, but you're loading up in one file, specifically, that was looking for a different name. And you'll see when we start making the components where that comes into play, cuz it's kinda hard to visualize that. But you'll see, so things like controllers and templates.

[00:01:34] Like, it's great to have named controllers, and in fact, we will, but it'd be really cool if I could just call it a controller inside of the file that needs it, right? So that's where you'll see stuff like that. So it also keeps things kind of the same, but not really.

[00:01:48] So it's like, you want strict, but then you kinda backed out of it, all right?
>> Off Camera 1: [LAUGH]
>> Scott Moss: [LAUGH] You went for it, but then you're like, no, no, no, I'm not ready, I'm not ready, so.
>> Off Camera 7: I can think of two other scenarios when you might wanna use it.

[00:02:03] One where you have a similar module that you wanna replace for one that's existing.
>> Scott Moss: That's true.
>> Off Camera 7: And rather than going through and refactoring all your code to use the new module, you just say, as, and then that name.
>> Scott Moss: That's true.
>> Off Camera 7: And the other is, if it's like a really long name and you don't want to have to retype that, incredibly long name.

[00:02:22]
>> Scott Moss: Yeah, I remember really bad, it was a really long name. Yeah, I ain't digging that, that's for sure. So those are some really good reasons too. Sweet, so like CommonJS, the path to the modules is relative to the current file, all right? So, just remember that, it's relative to the current file.

[00:02:38] This is CommonJS specifics or webpack. And jspm, if you're using jspm, it's not gonna be relative to the current file, it's gonna be relative to whatever you told jspm was the base URL. So that might be the folder you're serving. So it would be relative to that folder.

[00:02:52] So remember, if you're using jspm, it's a little different. This is why we're not using it right now. It's a little wonkier to work with. So here's examples of working with many imports and exports in the same module. It's very, very, very super, it's as you would think it is, it's just like with CommonJS.

[00:03:09] So in app.js, if we wanted to import multiple modules, we can do this. So we'll use the brackets, and we'll say, module 1, comma, module 2, comma, module 3, from this file. And the way that will look on the appropriate file is, you would define your modules, and then you would just export them at the bottom, just like you imported them in the other file, with the brackets around them, same syntax.

[00:03:32] So the way I remember this is, if I import it like this, it's going to be exported the exact same way. They look exactly the same. Or what you can do is just place export in front of, actually, there should be a var in front of these. So it would be like, export var module 1, export var module 2, export var module 3.

[00:03:51] So you can do that as well, however you want to do it. It's the same thing as doing module.exports or exports dot, just like in Node.
>> Scott Moss: Does everybody get that?
>> Scott Moss: Cool. So, you might be thinking, Angular already has a module system, all right, angular.module. How does that work with the ES2015 module system?

[00:04:22] Or does it work with it at all? Has anybody ever tried to use those two together? Has anyone even, have you? What's your experience with it?
>> Off Camera 3: Actually, it was great.
>> Scott Moss: It's great?
>> Off Camera 3: Yeah, it's good.
>> Scott Moss: That's good. I've heard some stories of people who were just like, I don't know what to do, I don't get it.

[00:04:39] And I've heard other people say, this is great, this is fantastic. And I think the problems revolve around, like, what system takes control? Where do I register my things? How do I stay organized? I don't know what's going on. I'm writing this same code over and over again.

[00:04:53] Or, like, this just feels wrong, I'm doing a lot of getters and not a lot of setters, which is an anti-pattern in Angular. So how do we get around that? So there are a few approaches. The one approach that I've seen a lot of people do is, you can have just one Angular module and rely completely on ES2015 modules.

[00:05:10] So you'll just make an Angular module called App, and then you'll just register everything on that module, you'll just pass that module around to all your ES2015 modules and register everything on that. Which is great. This is fine, but I don't really like it, because I do a lot of testing.

[00:05:25] I'm crazy about testing. And it limits like a lot of flexibility. So when it comes to testing, Angular, if you've ever tested it, you know you have to load the module up and mock it. Now, if everything is tied to the module, that means every time you write a test and you do that before each, and you load the module up, you're loading the entire application every single time you write a test.

[00:05:46] That's not that fun. Then you have to start figuring out all these dependencies and where they came from. And now you can't even get the tests to run, cuz you're trying to track down different dependencies. So I don't really like that. And it limits the flexibility. Now I can't really take my component out of my application and stick it in somebody else's application, right, cuz it's relying on this stuff.

[00:06:06] There are some ways you can get around that, but still, the abstraction is just like, is it really worth it? The other approach is what we're going to be doing is, we're going to create a new Angular module for every single component that we make. So it's going to be very redundant, you're gonna be writing the same thing over and over and over again.

[00:06:22] But for good use. So now we'll be able to test an individual module by itself, completely isolated from the entire application. It's just like, I just wanna test this module. Because it doesn't care, it doesn't know who its parent is. It doesn't need to know, it's just its own instance.

[00:06:36] And it's going to be super flexible, because now if you were working with a team, you can work on these separate modules completely isolated from each other. You can even have these modules in different repos, right, and then compose them later on, because they're completely isolated. Which I think is really, really great.

[00:06:50] If you have many applications that share the same functionality, you can create these modules in different repos and then import them somewhere else and somewhere else, which is really, really cool. So I really like that. But like I said, it's a lot of boilerplate and a lot of repeated code with this approach.

[00:07:03] The way I think about it, the more you write it, the more you understand it. So you get to the point where, like, it's a lot of repeated code, but I get it. And then what we're gonna do tomorrow is, I'm going to show you how to automate this so you can just type in one command, and it'll just spit it out for you anyway, so you don't have to write it anymore, cuz it's the same pattern.

[00:07:20] Any questions on that?
>> Scott Moss: All right. Okay, so there are other patterns using import and export, default modules, named modules, and handle that. But what we just talked about above is what we're mostly going to be using. So we also talked a little bit about the assignment stuff.

[00:07:42] This is really cool. I'm sorry, the reassignment or the aliasing. You can also do things like, just to touch on it, just so you know. So for instance, if I had this, I had export. And then I was like export thing as default, but I also wanna export other thing.

[00:08:10]
>> Scott Moss: What I can do now is up above, I can say, I can call this whatever I want. I can just call this whatever. That's gonna be thing. Then I can put a comma, and then I can export other thing.
>> Scott Moss: The way this works is, because I exported thing as default, I can now call that whatever I want.

[00:08:34] So that's what I call it up here, or whatever. And then put a comma after it. And because this is in the brackets and is not default, I have to still write this in a bracket and say other thing. So you can do stuff like this. So it gets kind of crazy.

[00:08:46] Then you start using ES7, you start be able to export imports. So you can say, export from. Yeah, it's really crazy. You can start exporting your imports, which is really cool if you start organizing stuff. But we're not gonna talk about that stuff. So those are some more advanced patterns.

[00:09:06] But the stuff we just talked about above is mostly what we're gonna be using. So things to remember when dealing with this stuff is, you can export an assignment expression. Remember that. I think a lot of people forget that you can do that. What I mean by an assignment expression is this.

[00:09:22] So if I say export a variable name equals whatever, I'm exporting this expression, this assignment expression. You can do that. Just put the export word in front of it, it's gonna export it with a strict name. You can totally do that. If you don't wanna do that, you could just say at the bottom, just say that.

[00:09:42] Same thing, right. There are times where you have you to do this one. And there are times where you don't have to do this one and you can just get away with this, and you'll see why. Okay, another thing to remember is, the brackets on the import and exports are not object literals, all right?

[00:10:01] They're not key-value pairs. Get used to seeing those brackets used in ten different places, they're just not obvious. I wish there was more characters on a keyboard, I wish they would use something else, but I don't know what else they could use. It would be really cool if they could just use something else.

[00:10:14]
>> Off Camera 6: They could use Unicode characters.
>> Scott Moss: They could, but then people would complain about writing Unicode characters, like, man, we've got to write an emoji to use this, [LAUGH] this is crazy. So people would complain about that.