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.
Conclusion
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.