Usually our route contains some identifier as parameter which we then read in the activated component to fetch further data to be displayed. However, in some cases we might be better served to resolve that data before the actual component gets activated. The Angular router allows us to implement such thing by using a so-called route Resolver
. In this lesson we’re going to take a closer look and implement one by ourselves.
Instructor: [00:00] In our setup here, we have a people routing module, which follows the routing module pattern here. We have a simple path, which specifies whenever that people segment is called, and then a variable part, which in this case is the person ID, then visualize that person detail component.
[00:17] Now, what happens inside the component is that we basically in the ngOnInit registered to the router params. We use here the pipeable operators and we use a switchMap for getting here, that route parameter, which via that little neat trick here, we convert from a string to a number.
[00:36] Then we basically pass it on to our people service, which on the other side, simply returns an observable from a static part here, of a set of people. In the interim, if we execute that and specify here people one, we will see how the data gets displayed. If we switch to two, another person gets displayed, and so on.
[00:55] Now, while this is a perfectly valid approach to get the data inside your routed component, we would like to move that logic, however, outside that component. To move it to the phase where we navigate from another route to this route, here.
[01:09] This can be done by using so-called route resolvers. The first step is to create such a new class. Let's call that personResolver.service, which is a normal Angular service class. Let's in here, just scaffold. Now, what we need to do is to implement a specific interface, which is here called resolve.
[01:34] For now, we resolve any kind of data object, because we don't have actually a class here. This is a simple example. Otherwise, you would specify here like person class or person interface. Now, if we implement that interface, we get a method that is called resolve, which takes in a couple of parameters. Let's import all of them from the Angular router.
[01:56] The next step is now to move that logic over from our person detail component here. Let's copy this, and move it inside here. Next, we need to get here the people service, so let's get that injected in the constructor, just as we usually do. Then we need to resolve here the different kind of parameters.
[02:16] As you can see here, we get already in the resolve method as a parameter route, which is the snapshot of the current route. We actually don't need to subscribe to the parameters, but we can directly extract them here.
[02:27] Let's say something like person ID is equals route.params, person ID. Again, let's convert that to a number. Now, we can simply invoke our person service by giving it here that person ID. We can remove the remaining part here.
[02:47] Now, let's quickly take a look at how that resolve interface is being constructed. If we take that resolve method here, we can see that as a return type, it expects either an observable, a promise, or a simple value.
[03:00] That's a really convenient part, because in this case, for instance, we return an observable, so we don't actually have to subscribe here. We can directly return that observable to that resolve function. Great, so our resolver is implemented, and like with any Angular service, we also need to register it, of course, in the providers section.
[03:18] Let's import it here, personDataResolver. Then we need to jump basically to the route definition, and the people routing module, and register our resolver here. Here, we can use the resolve property, which is part of that routing definition. Then we give it a name, which in this case is person, and then pass it in here, the resolver.
[03:41] Now, that name here will now be available within our routed component. Let's go to the person detail. We can remove here actually the whole part, because we won't need that anymore. We still need, however, the active route. What we can do here is to say this.activeRoute.data, and we subscribe to that.
[04:02] Now, inside that data, we have a variable which is called exactly as we specified it in the resolve part of our people routing module. Basically, this one here. This will now contain our resolved person, and we can simply associate it here to our person variable. If we save this here and refresh again, you can see it still works.
[04:27] Now, the difference is our data is no more loaded here from our person detail component, but rather it is loaded within our person resolver, which gets called whenever we route from a different route via that people person ID.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!