We'll take a close look at the role that a Single-Page App's router plays in a typical app and then introduce Angular's "light touch" implementation, which relies heavily on services to do the heavy lifting. What begins as a simple mapping of URL expressions to components can quickly become a dependable finite state machine that readies our app for rendering a particular screen.

We'll build two flavors of a multi-URL application, each of which involves a list of records, and a "detail view" of a single record. Through examining the consequences of re-organizing our hierarchy of routes, we'll clearly understand how an application's URL, route handlers and their respective components work in concert to create the illusion of a server-rendered app experience.

Guards are a special type of service that we can include with our route definitions. In essence, what these guards provide us with is akin to lifecycle hooks for a given transition, giving us the ability to customize entry and exit validation (and more!). We'll study a few common use cases, and lead up to building a route guard of our own

Create a guard that kicks users out to the /login page if they're not authenticated. Preserve the user's original intent, so that if they complete the login process, they're redirected to where they were originally trying to go.

Resolve guards allow us to contain asynchrony within our routing layer, by loading the data our components need before rendering. This greatly simplifies our components, in that they can be designed to receive objects and arrays, instead of promises or observables that resolve to the values of interest.

Begin with the solution to our "course list" routing exercise, and replace the hard-coded fixture data with real HTTP requests to the Mike Works API. Despite the fact that data is now asynchronously obtained, you should be able to get your app working again without touching anything outside of the routing layer.

Break for lunch