When our routing configuration gets more complex it is suggested to organize routes using the so-called “Routing Module” pattern. Simply speaking, this means moving the route definitions and everything else related to routing into its own dedicated NgModule, a sub module of the feature module you’re working on. In this lesson we will take a look how to migrate a simple routing configuration to reflect the Routing Module pattern.
Instructor: [00:00] In our neat little application here, we have defined a couple of routes where you can see here defined in this array here. Those are being registered down here, and a router module for route, and app module.
[00:14] What jumps to one's eye immediately is, when you look at a route configuration, we have here two components, one in the people module and one the context module. Both components reside inside separate dedicated modules, which follow the normal pattern of how you structure Angular applications. They have their own ng module where it defined their components.
[00:36] Similarly, we will also like to structure our routes. As you can imagine in a more complex application, this route definition here might get quite complex and quite huge, and turns into being very hard to maintain and to manage.
[00:50] Therefore one suggestion which has to be taken for sure is to externalize this in its own file and manage it there, but anyways it will be much cleaner to further split those out into their own modules.
[01:03] This is exactly what a routing module pattern suggests, which is one of the patterns that should be followed according to the official Angular documentation. Let's take a look how this works. Let's start with the people module here and let's similarly define a new file which we call people-routing.module.
[01:23] This file is a normal ng module. We need to import the ng module from Angular core, and we define ng module section below here, and we also export it. We call it people routing module.
[01:37] This follows our official style guide on angular.io. Next we need to define our routes, obviously. We can go back to the app module and copy out that person route which is defined inside here.
[01:50] Let's remove it from here, for a second, jump back to our people routing module. Here we define our routes, which is an array which defines here our people component.
[02:02] Obviously, we need to import that as well. Once we have that, we can then import the routing module, so import the router module from Angular router, and we can go down into the ng module section.
[02:15] In the imports part, we basically declare the router module. At this time, we don't call for route, as we did in the global router path, but this time we define for child and we pass in the routes definitions. Last time, we also need to export the router module such as that can be then consumed by others.
[02:36] Once we have defined the people routing module, we obviously also need to register it on its own people module. That happens directly in the import section. Here, we defined people routing module when we import it from where we have defined it.
[02:54] We need to do exact thing also for the context part. Let me just quickly do that for you. Great. Once we have both modules here defined -- so the context routing module as well as the people routing module -- we can go back to our app module and do the very same thing also for the application itself.
[03:13] We take out those definitions. We create its own file AppRoutingModule. Here, we need to import the very same things. Then, we can copy in here our route definitions.
[03:37] We also need to obviously import their components to the home components here [inaudible] component, and the not-found component. All of them belonged to global app module, as you can see it get import directly from local directory.
[03:53] Finally, we need to also register them. Here you have to pay attention, because now we have define obviously for route and pass in those routes definitions. Great. We have concluded most of the parts we need to define a jump back to our app module.
[04:08] We can remove here parts like the contact list component and a people leader component, as we haven't really register down here, because they have their own registrations in their modules.
[04:19] What we need to do here is to import AppRoutingModule, and finally we have to register all of them down here. The people module and the context module have already been registered. Here, we need to define AppRoutingModule as the last part.
[04:35] The sequence here is very important. Each of these defines their own type of routing modules, which have to be defined before and at the very last comes to AppRoutingModule. Because as we know the routings are being processed by sequence, therefore moving around these could have some strange side effects.
[04:55] If we save and refresh here the browser, we can see that the home route perfectly loads. We can then also go to the contacts list, and the contact list works and also the people, person detail works as we expect.
Well I think that's fine. Normally for the CommonModule
this is how it is being done. But as you mention, there's nothing wrong for creating a dedicated module and exporting it from there and then in turn import that module everywhere else.
In fact, normally in an application you have what's often called SharedModule
, where you import all of the modules that will be used throughout the application anyway. A typical example is the imports from the Angular Material library (if you're using that). Check out the official Angular docs about the NgModule FAQ for a detailed explanation on this.
You mentioned that, inside app.module.ts --> inside imports: [ ] - the order of the modules we import matters. I was not at all aware about it. Can you throw some light on it, how should we go about ordering them and why is the routing module added at the last. What should be the ideal order? I tried to find that on the documentation, but I didnt find much on it. thanks.
Hey,
yes the ordering is important due to how the router resolves the routes. The reason is that the router tries to find a matching route using a depth-first algorithm. As such you might theoretically get different results, given you have multiple route configs that match the same URL.
But as said, normally this isn't an issue and in general I'd recommend to structure the routes in a way this doesn't happen (just to avoid confusion) :)
Those 2 new modules both import the common module. however this common module is not imported into the app module. is it a good idea to import this common module into the app module and export it to the other modules?