Page 10 - MSDN Magazine, September 2018

The Working Programmer TED NEWARD How To Be MEAN: Routing Angular
Welcome back again, MEANers.
Up to this point, despite all we’ve accomplished, everything has
essentially been done entirely within the scope of one “page.” While this does make sense for some single-page applications (SPAs), users of Web apps, even the most sophisticated Web apps (or the most sophisticated users) generally follow some of the established principles of the Web, like accessibility via a URL. That is to say, I should be able to “jump” to certain parts of the application by simply entering the appropriate URL into the browser, or bookmark a page while I’m on it, and so on. The ability to navigate “inside” the application is one of the hallmarks that distinguishes the Web app from the desktop or mobile app, and it’s an important feature that should be supported.
In an older, more traditional Web application, this is handled by the very nature of the traditional ASP.NET (or Java servlets or Ruby-on-Rails or PHP or ...) application: Everything is a separate and distinct Web page that’s manufactured on the server, then sent to the client for rendering. Within an SPA, however, most (if not all) of the rendering is done entirely client-side, and you only go back to the server when you need data or have to invoke some behavior that needs to remain tucked away on the server (such as modifying data in a shared database, or perhaps invoking a separate Web service hiding away behind the firewall on the user’s behalf ).
Thus, within most SPA frameworks—like Angular—a different mechanism is required in order to provide the kind of “scoping” or “segmenting” that page boundaries provide. In essence, you need some kind of tool or mechanism to change “pages” within the SPA, essentially ripping out whatever components are currently being displayed and replacing them with a different set of components, so that to the user, it looks like you changed pages, but without having to do the HTTP round-trip that navigating to a new page normally entails. Within Angular, that mechanism is called “routing,” and it’s the responsibility of the Angular Router. (And you, of course.)
Routing Fundamentals
To better grasp how routing works, let’s assume a standard master- detail style of application: The first page will display a list of items in which I’m interested (such as speakers at a conference) by some sort of summarization (such as by last name and first name). When a user wants to “drill down” into a more detailed display of a single item, they’ll click on that item in the list and I’ll bring up a more detailed view. In Angular terms, this means I want to have two components to work with: a SpeakerListComponent, to
display the speakers by name, and a SpeakerComponent, to display the full details of that speaker. This is pretty standard master-detail stuff, and more importantly, it’s the central staple of countless busi- ness applications. Naturally, there’re other (perhaps better) ways of building a business UI, but this serves to get the core point across—I need to figure out how to route from the SpeakerList- Component to a given SpeakerComponent, and pass the selected speaker in while I’m at it.
A natural place to start with routing is with the collection of routes themselves. It’s typical to want the homepage of the app to be the “master” view (the list of speakers), so let’s start with that. As routing is usually something that’s application-wide, or at least module-wide, typically routes are defined in the app.module.ts file, by constructing a Routes object imported from the “@angular/ routing” module:
const appRoutes: Routes = [
{ path: 'speakers', component: SpeakerlistComponent }
];
Note that the routes look essentially the same as they’d look in other Web technologies, like ASP.NET MVC or even Ruby-on-Rails. Routes are, at heart, a mapping of a URL path (without the leading slash) to a component that should be displayed. So, in this particu- lar case, when a user navigates to “http://localhost:4200/speakers,” they’ll be rewarded with the list of speakers at the conference.
Come to think of it, I’d like the “/” path to redirect to the “speakers” route, so that coming to the “homepage” would automatically redirect to the list of speakers, so let’s add that:
const appRoutes: Routes = [
{ path: 'speakers', component: SpeakerlistComponent }, { path: '', redirectTo: '/speakers', pathMatch: 'full' }
];
Of course, the other thing that’s often needed is some kind of “Oops!” page to be shown if the user goes to a URL that doesn’t exist on your site, so you also need a “wildcard” route that will display the PageNot- FoundComponent you’ll have the intern build over the summer:
const appRoutes: Routes = [
{ path: 'speakers', component: SpeakerlistComponent },
{ path: '', redirectTo: '/speakers', pathMatch: 'full' }, { path: '**', component: PageNotFoundComponent }
];
Note that the wildcard route doesn’t really look any different, aside from the “**” path, but it’s deliberately put at the end of the Routes table. This is by design, because routes are evaluated top- down, with the first match “winning.” Thus, if the wildcard route were at the top, you’d always be showing off the intern’s summer work, no matter whether the user navigated to a correct route or not.
6 msdn magazine