Putting it all together

We now have area or feature routing that contains child routes, and all the routes related to the Workout Builder are now separately contained in their own routing configuration. This means that we can manage all the routing for Workout Builder in the WorkoutBuilderRoutes component without affecting other parts of the application.

We can see how the router combines the routes in app.routes.ts with the default route in workout-builder.routes.ts, if we now navigate from the start page to the Workout Builder:

If we look at the URL in the browser, it is /builder/workouts. You'll recall that the router link on the start page is ['/builder']. So how did the router take us to this location?

It does it this way: when the link is clicked, the Angular router first looks to app-routing.module.ts for the builder path because that file contains the configuration for the root routes in our application. The router does not find that path because we have removed it from the routes in that file.

However, WorkoutBuilderModule has been imported into our AppModule and that module in turn imports workoutBuilderRoutingModule. The latter file contains the child routes that we just configured. The router finds that builder is the parent route in that file and so it uses that route. It also finds the default setting that redirects to the child path workouts in the event that the builder path ends with an empty string, which it does in this case.

If you look at the screen, you will see it is displaying the view for Workouts (and not as previously Workout Builder). This means that the router has successfully routed the request to WorkoutsComponent, which is the component for the default route in the child route configuration that we set up in workoutBuilderRoutingModule.

This process of route resolution is illustrated here:

One final thought on child routing. When you look at our child routing component, workout-builder.component.ts, you will see that it has no references to its parent component, app.component.ts (the <selector> tag has been removed, so  WorkoutBuilderComponent  is not being embedded in the root component). This means that we have successfully encapsulated WorkoutBuilderComponent (and all of its related components that are imported in the WorkoutBuilderModule) in a way that will allow us to move all of it elsewhere in the application, or even into a new application.

Now, it's time for us to move on to converting our routing for the Workout Builder to use lazy loading and building out its navigation menus. If you want to see the completed code for this next section, you can download it from the companion codebase in checkpoint 4.3. Again, if you are working along with us as we build the application, be sure and update the styles.css file, which we are not discussing here.