Why do we want to debug the router? Well, sometimes the route doesn't do what we think it should do; when that is the case, it is good to know more about how the routing acts and why. To enable debugging, you need to provide a configuration object that enables debugging, like so:

RouterModule.forRoot(routes,{ enableTracing: true })

Attempting to route to, say, /products from our start page will look like this:

What we can see here is that several events are triggered:

• NavigationStart: When the navigation starts
• RoutesRecognized: Parsing of the URL and recognizing the URL
• RouteConfigLoadStart: Triggered when reading a lazy load configuration
• RouteConfigLoadEnd: After the route has been lazy loaded
• GuardsCheckStart: Evaluating the router guard, that is, can we go to this route
• GuardsCheckEnd: Router guard check done
• ResolveStart: Attempting to fetch data that we need before routing to a path
• ResolveEnd: Done resolving the data it was relying on
• NavigationCancel: Someone or something canceled the routing
• NavigationEnd: Done routing

There are a lot of events that can happen. As you can see from the preceding image, our bullet list covers more events than the image showed. This is due to us not having any modules that are lazy loaded, so those events aren't triggered, and also that we haven't set up any resolve guards, for example. Also, NavigationCancel doesn't occur unless the routing fails for some reason. It's important what events are triggered and when, so that you know what part of the code might be wrong. We will look closely at the events, GuardsCheckStart and GuardsCheckEnd, in our next section on determining whether you are authorized to visit a specific route.