This course has been updated! We now recommend you take the Angular 13 Fundamentals course.

Check out a free preview of the full Angular 9 Fundamentals course:
The "Angular and ES6 Modules" Lesson is part of the full, Angular 9 Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Lukas answers questions from the audience about when to create a module when using Angular, explains that every component does not need a module, and describes why a module is necessary when using lazy loading.

Get Unlimited Access Now

Transcript from the "Angular and ES6 Modules" Lesson

[00:00:00]
>> The question is, is it a good practice to create a module for a newly created component? And I'll touch on this more when we get into component driven architecture, but it depends, and so I definitely will not, I will create a module to group a set of related components.

[00:00:21] So for instance, I might have a parent or a container component and then I might have some sub components that are related to that, where I'm dividing out some functionality. Well, I'm not going to create a module for every one of those components, but I will create a module to encapsulate a group of related components.

[00:00:40] And typically how I think of that is how are we dividing up features? And so, generally, I think a routing table, if you click and you go to this new route, that's a pretty good indication that you probably have changed context. And I may create at least a top level component for that route, but possibly a module.

[00:01:07] And if I'm doing lazy loading definitely. So my answer is, I would not create a module for every component for the sake of having a module. But I would create a module for a group of components where it makes sense from an organizational standpoint. So typically that would be maybe a top level container component, maybe, but if I'm lazy loading that top level component, definitely.

[00:01:38] So hopefully that answered that question.
>> The next question, there's kind of two related questions.
>> Sure.
>> One doesn't really understand, yes six module. And then the other question is kind of NgModules versus ES6 modules. Why did Angular create their own module system?
>> Right. So that is a really good question.

[00:02:08] The question is, you have, why do you have ES6 modules and engine module? In other words, why do we have a language level module system, and really an Angular module system. And so, let me show you in the code, why we need really just the ES6 module system.

[00:02:32] So you'll notice here that, let me pull up a just another one. So this is our routing module and we haven't really done anything with this but notice export class AppRoutingModule. Outside of this right here, if I delete this, there is nothing Angular about this. And so that's the other thing that Angular has done in really made a shift is there leveraging native language features where they can which I think is really good.

[00:03:06] That you're reducing the footprint of the framework instead of having to create all these, the shims in these layers to do that, so this right here, this is nothing more than that ES6 or TypeScript, which is a superset of ES6. And so how do I make this app routing module available to the rest of my source code?

[00:03:30] Well, prior to ES6 module system, you just had all these imports in your inner study XML, or you had to have some crazy build system. Well, with module systems, it's easy for me to say, okay, I have this routing module. And I want to make this available to my AppModule.

[00:03:52] And so when this compiles, I need to do it in such a way that App Module knows about RoutingModule, just the source code itself. And so you can see here that I exported the module. And then up at the top, I'm able to import that. And now it's available for consumption within this module.

[00:04:15] Or really this class and so, this is how to source code level at a language level you're able to essentially pass source code around that it satisfied those dependencies. It's really import-export. The reason why we have the Angular module system on top of that, is because when we do things like lazy loading.

[00:04:48] We need to be able to communicate, to Angular that certain things exist, even though you may not be using it right then. And so, in terms of optimizing your build and providing additional information to Angular to say this is precisely what you need to run, or here's some additional things that you need when you wire this up.

[00:05:14] And so ES6 modules are strictly to just indicate to Webpack that this is how this is gonna be put together. NgModules or angular modules are there to say this is how we're going to put the Angular application together in a way that is performant, and that makes sense.

[00:05:33] So especially when you're doing lazy loaded modules, being able to declare that, hey, you don't know anything about this yet. But this is how you find this module and this is this is where this exists. And so that's why that is it. There was a point in time, when this did not exist NgModule.

[00:05:55] And they ran into some performance issues, they wanted to do lazy loading in a couple different things. And another thing is actually tree shaking, optimizing the build that Angular is able to look and say, this is everything that I need. I don't need everything else. And it can create this optimized AOT build, which I can talk about later.

[00:06:17] When they reannounced NgModule, just a funny story. I just recorded a front end masters workshop. And for months later, they're like, we're reinducing NgMoodle and I just laid on the ground and I cried because it really invalidated that whole workshop. So I had to basically come back and redo it.

[00:06:40] So I would say the first four versions of Angular were, like angular two and three and four was a bit tomaculous now that we're at nine, it's a lot better. So that's why there are two kind of module systems in parallel