We are building an application on Angular 2. We’ve beeing working with Angular 2 since Beta 8. Recently we have made the upgrade from RC1 to RC3. In this upgrade, it seems as if the official Angular 2 docs have been updated to reflect usage of the ‘new’ router. Note the big disclaimer at the top.

The Component Router is in alpha release. This is the recommended Angular 2 router and supersedes the earlier deprecated beta and v2 routers.

There is also a great article on thoughtram.io, Routing in Angular 2 Revisited, written by Pascal Precht, which does a great job outlining the new features of the new router.

Out with the old, In with the new

Managing the way our application handles navigation has been somewhat static to date. Mostly a navigation component with static routeLinks littered throughout. We have always wanted to make this component a bit more dynamic. But, our investigations with the “old” router, always led us into complex solutions.

So, with the news, we decided to take the “new” router for a spin to see if we can’t more simply solve some of our navigation issues, with something more native and simple.

If you are interested, the entire example is available here. This example is forked from Pascal Precht example mentioned earlier.

Gettings things setup

One of the most interesting things you’ll find with the new router is that you can use a plain <any>[]. TypeScript will cast it to the correct RouterConfig type. Which boils down to an interface array of type Route. All of fields are marked nullable, which makes this very simple to configure.

Because this is an interface we can provide members that are not part of the Route type and the router won’t get upset. This is super cool because now we can tie information that is relevant to the route, directly to the route config itself.

As you can see in my example, we’ve attached members name, description, showInNav which are not required by the router. In order to feed this into the router, you’ll need to use the providerRouter() and send the result into the providers array on your bootstrapper.

Viola! That’s pretty much all you’ll need to get things going.

Generating some navigation

Now that the router is all wired up you can go upon your normal business using routerLink very similarly to how you used to. But, since this information is stored in an <any>[] why not use it as a data source for your navigation.

As you can see it’s fairly straight-forward to use the same RouterConfig supplied to the router for consumption elsewhere. Now you could have done this before, however, it required you to reflect data out of the @RouteConfig metadata. The new router makes this very much less painful.

Just for kicks

Just for kicks, I wanted to exercise again, how cool it is to have this data readily available. We wanted the application header to respond to route events. Allowing us to create a consistent, and generic application header.

What we’ve done here was have our HeaderComponent subscribe to the events being emitted by the router. There are several types of events, but, we only care about the RoutesRecognized events. Simply filter them out and subscribe. When the RoutesRecognized events fire off, the HeaderComponent will retrieve the Route.path and find a match in our AppRoutes constant, and assign the result to the routeData member.


We are very much impressed with how easy and flexible the new Angular 2 Router is. It allows for a bunch of new scenarios natively, without having to resort to “workarounds” or “hacks” to get the desired behavior.

If you are interested, the entire example is available here. This example is forked from Pascal Precht example mentioned earlier.

Robert Sweeney

Developer consultant. Microsoft and web technologies. .NET, C#, F#, PowerShell, Functional Programming, Automotive enthusiast (donations for Bugatti being taken).