Our Master/Detail relationship is indeed working, yet it has some major flaws. The current in-page navigation approach, for example, is completely different from the original plan. We wanted our users to switch back and forth between the HomeView containing the list of quizzes and a dedicated QuizView whenever he selects one of them, but the app doesn't do that; it just opens something like a "quiz detail panel" under each list. Not just one but three different panels, one for each item lists--that doesn’t make any sense! We need to fix that as soon as possible.

While doing that, we also have another issue to solve. You may have noted that, regardless of what we do within our app, the URL in the browser's address bar is always the same. It will mean that we won’t be able to share, say, a URL that will directly lead to a specific quiz; we’ll be forced to share the starting URL because it is the only supported one.

Wait a minute, isn’t this our Native Web application’s most expected behavior? This is what the Single-Page approach is all about after all, isn’t it? The answer is no. The Single-Page application approach has nothing to do with keeping an immutable URL in the browser's address Bar. URLs are not pages, as the name suggests; they are unique identifiers for accessing resources.

Standard Web applications are usually built upon a rather small number of pages that answer to multiple URLs and serve specific contents based upon query string parameter values and/or URL rewriting techniques. Single-Page applications make no exceptions, as they can adapt their inner state according to the request URL and also track the user navigation by updating the browser’s address bar accordingly. This technique is called client-side routing, which has the same meaning as navigation; luckily enough, the sample SPA shipped with our Angular template already implements all we need to set everything up. Remember the counter and fetchdata components that we removed back in Chapter 1, Getting Ready? They also had their own client-side routes registered in the AppModule and implemented in the NavMenuComponent, which we also removed because we didn't need them anymore. Now that we need something similar, all we have to do is go back there and get the job done.

Before doing that, we need to understand how the router can help us achieve what we want, changing the browser’s location and history whenever the user navigates within the app, without triggering a new page request to the server.