When you're just starting out with Angular, you'll probably write your app as a single module. This works fine for small apps, but for more complex production apps, the single-module approach will quickly get out of control and make the code hard to maintain.
In this course, you'll learn all about moving from a small single-module Angular app to a larger, more complex multi-module architecture. Along the way, you'll see a practical example of how to break an app down into discrete sections in order to minimise and organise the complexity that growth of the codebase brings.
1.Introduction2 lessons, 08:35
2.Refactoring to a Multiple Module Architecture5 lessons, 46:33
3.Conclusion1 lesson, 00:43
Hi folks, it's very common when getting started with Angular to build applications using a single root module which all of your other components and services connect to. This is fine for small applications, but as your projects start to grow, there comes a time when it makes sense to move to a more modular architecture and break the application up into multiple modules. In this course, we are going to take a small example application and see how we can add smaller modules like a routing module or larger features modules containing multiple components and services. We can also look at creating a completely independent third party module that we can share between all of our projects. Let's make a start in the next lesson by installing the initial starter site and getting everything set up and running. Thanks for watching.
Hi folks in this lesson. We can get everything set up and ready for the coding examples, which I'd recommend you follow along with in order to maximize your learning experience the repo for this course does also contain a branch called completed- app, which has the completed solution inside it as the code will look at the end of the course you can use this for reference purposes. This branch also contains a series of individual commits where each commit matches what that code will look like at the end of each lesson. Let's get the example repo cloned in and make sure that we can run the application We can also take a look at the existing architecture of the example out to see what we'll be working with. You need to have casing soot, so if you don't have it already head on over to git-scm.com, and follow the installation instructions for your platform. You'll need to have NodeJS installed, and the Angular CLI. The CLI requires node 8.9 or higher. So if you don't meet this requirement, you can go to nodejs.org and download the appropriate installer. With node and gets installed, we can then install the Angular CLI We can do that using the following command. Once we've installed the angular cli clone link we can then clone the example repository to our local machine so that we can develop the example up. You should have the command line focused on the directory where you would like the reboot clone tool Than we can run this command to clone the repository and move into the newly created root directory. Once we've cloned the repository we should do an NPM install and that will install the local dependencies for the example application. So now everything should be ready to begin. Let's do a quick test and make sure that we can run the example application in the browser. We can launch the built-in development server for Angular using the ng serve command. And as long as we get the message at the bottom there saying compiled successfully, we should be good to go. So we'll get a local host URL in the output here, let's copy that. And we should then be able to paste that into a browser. So the exampler is some kind of social site, the default route is for a list of posts that the user is following and you should be able to click into One of these links and go to the full post. It's all just and there's also a group section. And this lists groups that the user is a member of and again, there's a view group link that we can use the view the actual group itself. So there's no database or anything, it's all just lorem ipsim and smoke and mirrors with some JSON files. But the app itself is not important, we're more interested in the architecture of the app. So let's take a look at how it's currently set up. So it has the standard Angular app directory structure with a node_modules folder, an e2e folder, and an src folder inside the root of the application, along with all of the usual node and git files. The src directory is where all of our app files reside. And in there, there's an app folder, an assets folder, and an environments folder. And there's a bunch more application specific configuration files which we aren't to concerned about in this particular course. Let's just take a quick look inside some of these directories and inside some of the files, inside the environments folder we have. A dev environment and prod environment. And in the dev environment there are paths to the JSON files which contain the mock data. And the production version. These are just empty strings because normally these would hook into some kind of backend API. But for this example application there is no backend. We can actually build this application for production, but that's not the point of the course. The Assets folder contains things like images, so that could be avatars for the fake users, and it contains the actual mock data JSON files. And there are some SAS files for the styling. So we've got one for the layout and another one for the very minimal and grey theme. So this is a pretty common structure for small applications, the app folder. Contains all of the components which are organized into their own folders. But there's also a ton of loose files in the app-route. And these are a mixture of the route component, the route module, and all of the services used by the application and the associated unit test files. Some of the components such as static components like the Balance Us and legal components and each of these folders has just a small amount of files inside. So there's the HTML template file, the SAS file for the styling, and the component file, and a test file. So again, very standard angular componentcy-type folders. Some of the other folders contain a few more items. The dynamic components like the feed-item and feed-list and group-item and groups-list. These will have their own folders and inside these, as well as the standard kind of component files, like the template, the service file, and the component, we might also have some interfaces And even resolvers to get data for us. And that's the same for the feed list as well and the group folders. So in terms of organization it's not too bad. Most things are organized into their own folders but there are some new files as well. But it's not a great setup, either. So these are ready lock suits, folders and files in here, and if the application continues to grow and we continue to add more and more components and more and more services, it will start to become much more confusing and unmanageable. It will become a mess that is intimidating and hard to maintain and which nobody particularly wants to work on So the project will quickly die. So the aim of this course then is to re-factor the architecture to make it easier to add new features in future without just adding more clutter. We're going to change the architecture from a single root module to a number of different modules which are all added to the existing root module. So we should be set up and ready to make a start. Let's do this in the next lesson then and add our first new module. Thanks for watching.