News

Angular Routing Q&A: Moving Through Your Angular Apps

Deborah Kurata talks about the challenges of using Angular routing, types of parameters and more.

• By Lafe Low
• August 15, 2017

Angular continues to be a driving force in the development world. And now there are evolving techniques and tactics arising to help you getting the most out of angular development. We caught up with veteran developer, author and trainer Deborah Kurata to get some inside scoop on Angular routing in advance of her Angular sessions at upcoming Visual Studio Live! and Live! 360 conferences.

Is there more to routing than moving a user through different views of an application?
Absolutely -- we use Angular's basic routing features to navigate the user through the views (or pages) of the application. We use Angular's route guards to protect our routes. For example, we check that a user is authorized to access a specific route before letting them navigate to that route. And we determine if the user has unsaved changes and display a warning before navigating away from a route.

Angular provides many choices for laying out routes. With child routes, we insert content within a container to display a common header and footer across multiple pages, for example. With auxiliary (aka secondary) routes, we display content side by side. Picture a master/detail layout with the master data appearing in the top of the page and the selected detail displayed beneath.

If we need to pass data with a route, the Angular router provides three different types of routing parameters:  Required parameters let us define required data on a route, such as a customer ID when navigating to a customer detail route. Optional parameters let us pass optional, complex, or multifaceted data, such as search parameters that may or may not be specified. And Query parameters let us define sets of parameters we can retain across multiple routes.

Parameters are useful, but does the Angular router provide other ways to handle data with a route?
Indeed, it does. The router provides a data property we can use to pass a fixed object to a route. That is great for assigning a specific title or other route-unique information in a more generalized way.

And with a route resolver service, we can pre-fetch dynamic data for a page. So instead of routing to a page and displaying only part of that page as it waits the data, we can get the data first and then route to the page. The page then has all the data it needs to display all of its content. This provides a much cleaner user interface for the user.

What are some of the most challenging aspects of using Angular Routing?
One common issue I see when using routing is mingling syntax for the three different types of parameters. The syntax for configuring and navigating is different for required, optional, and query parameters. So you need to be aware of the differences and when to use each.

The more important challenge, however, is laying out the appropriate route configuration for the best user experience. This is especially important when working with larger applications. Should the application have an "empty" shell, such as recommended for Progressive Web Apps (PWA's)? If so, then the root route should not have a header, menu, footer, or other content. Those belong in a home or other component that provides a container for the other basic routes. Each page of the application needs an appropriate place in the routing hierarchy.

What exactly is lazy loading and how can developers use it to their advantage?
This is an important question because lazy loading can really improve the startup performance of an application. First impressions matter. We want to minimize the time between the user's request for our application and display of its first view. If we break our application into pieces, then when the user accesses the application, they only need to wait for the first small piece to be downloaded and executed before seeing its first page. The other pieces can then download "lazily" on demand, when the user accesses a specific feature, or preload asynchronously in the background.

We use routing to define which parts of our application are lazy loaded and for specifying our preload strategy. For example, we may have an admin feature we want to lazy load on demand. This makes sense because only administrators need this feature. There is no need to download the admin pieces unless the user is an admin and wants to work with that feature. Or we may have a customer feature that we want to preload asynchronously. That way it will be available as needed since it is used by most every user.

So yes, Angular routing can do so much more than move the user between multiple views of an application. For more details on how to use these techniques, check out my "Angular Routing" presentation at Visual Studio Live! Or my "Angular Routing" course on Pluralsight.