Transcript from the "Dynamic Route Params" Lesson
[00:00:00]
>> What happens when you want to look at a dynamic value? In other words, when you can't predict the route that you're going to, so take for instance, when we go into Pokedex, and Pokedex has different Pokemon, right? That is the way the Pokedex works. What if we wanted to actually render out the different Pokemon but we wanted to do you think based on the parameter in the URL?
[00:00:20] So an example of this might be, if we're looking at the Pokedex page, and you say, okay, theoretically what I'd like to be able to do is also then go to a page that goes to like go to/Pokedex/1. And that should call the first Pokemon. In other words, this part is dynamic because what we don't wanna do is define 1.view, 2.view, and etc.
[00:00:43] And so, how might that actually work? Well, when it comes to that, what we're actually looking at is around the idea of dynamic param IDs. So the way this works, is we go inside of our router, inside our playground. And what we have here, is we have a path here, that /Pokedex/ with a colon ID.
[00:01:08] And this is what tells it that it's going to be dynamic. And then from here, we can then say, let's create a Pokemon page cuz this would fetch a specific Pokemon in this particular case. Let me SSC this, and then let's just say Pokemon. And for now we'll just say number 100 to show that it's wrong as far as the URL is concerned.
[00:01:27] And then we'll just do component, and this time we'll just import the path at views/Pokemon page.view, Save, okay. So to prove that this works, we're gonna go ahead and on the Pokédex page right here, we will have a router link that goes to /Pokédex, and this time we'll do /20.
[00:01:48] Just that so it's something different. Go to Pokemon number 20. Okay, we see that here. And if we click on this, you'll see that it does correctly jump us over to the page. But what we need is we need to be able to pull in the dynamic data, right?
[00:02:02] How does that work? Well, when you used to do it in View 2, the way you would do it in Options API and you could still could, is you do this.route.params. That's usually what you would reach out for. But in an effort to get you all practicing with Composition API and seeing what an alternative form might look like, what might you reach for?
[00:02:21] Probably a helper method, right? So we have something called use route, cuz it's from view router. Then we can say const route = useRoute. And then before we do anything, let's just log that out real quick and show you what we get. This is the Pokedex page, I need to go back.
[00:02:38] So, in the Pokedex page, you'll see now, that we expand this out to the target. It has a bunch of stuff actually, params, name, meta, and then if you broke it down to like query stuff, there's a whole ton of stuff under there that you can unpack. But the one we care about is gonna be the parameters.
[00:02:53] So, let me go ahead and actually move this useRoute, cuz the where we need it is not the Pokedex page. We need to on the Pokemon page. Let me drop this over here instead. And so, now let's go ahead and go to Pokemon 20. And now we'll notice, actually we refresh, there we go.
[00:03:09] We have our route being rendered. And when we look at our params, you'll see that we have an ID of 20 in here. And where does this ID come from? This ID comes from what we named right here inside of our path. That's where it's actually been defined.
[00:03:26] So, well, we've got, if we want. We say route.params.id. And if we do that and refresh the page, you'll see, there it is, 20. That's all it takes. And so now your imagination can go from here, you could go to the Pokemon API. And then when you load the page, you can go ahead and fetch the right Pokemon, get its attributes, render it to the page.
[00:03:48] But for the sake of conciseness, we're just gonna go ahead and show that here just like this, route.params.ID. And then, just like that, you now have a dynamic page that can take any argument. And then, however you see fit, you can programmatically set up else conditions, if else, whatever not, to render the right stuff to your users.
[00:04:10]
>> What about params for parent routes?
>> Okay, so the question here is around params for parent routes. So what you're saying is that, if it's like, so basically lets get that real quick. Are you saying something like, if Pokerdex had then like on top of ID for the Pokerman, there was an additional thing for element?
[00:04:28] So then you might be on element page and you wanna look at your ID params?
>> Potentially.
>> Yeah, so I believe the moment you do the route basically, you should basically get everything that comes as a part of that route. And so, this goes beyond the scope of the fundamentals review router, but there's even things like nested views, and all those things that we can play around with.
[00:04:49] So, you should be able to get the parent from .path without any problem. And that's why it would be a good practice, for example, not in your router.js, to define another route that uses the same parameter like name. Like you wouldn't want to be like ID ID. So, I think that would actually probably, I'm almost certain that would break the about view router cuz it'd be confused.
[00:05:10] And so, in that particular case, that's where it's important to be just specific about what that parameter name is. And then the route should contain all of those parameters correctly appended into that object.
>> So you said nested routes, could you have like region was the thing you were saying?
[00:05:28]
>> Yeah.
>> Region/region ID or region name-
>> Yep.
>> And then underneath that have the Pokedex for that region, and then have a Pokemon page-
>> Yeah.
>> Parameter on that?
>> We can. And so, it's not part of this exercise, but since this is a question I do wanna show this for the nested.
[00:05:44] If we look at the docs right here, and we look at nested routes. The thing about nested route is it's easy to think of it like what we just did, cuz you see here, user Johnny profile, right? You're like, didn't we just do this pokerdex/ pokermon? This is different, because a nested view means that you have a router view inside of a router view.
[00:06:03] Meaning the rest of the page stays the same, and just that one section of the page changes based on the URL. So as you can see here, inside of this example, let me blow it up a lot. Is that the user page out here which is the shell, which is /user, is currently bringing in the Johnny child, right?
[00:06:21] So there will be user Johnny. But the nested view here is for the profile and the posts. And so you can almost think of it like tabs, where you don't want the whole page to rerender if you click on posts for Johnny. You want everything else to stay the same, you just wanna switch the tab that's inside of it.
[00:06:37] And so, nested views are basically this concept that without having to rerender the entire page, you can just render a portion of it and have that update based on the URL. And so, that can be as highly performant as well when it comes to doing things for your app.
[00:06:49] So I know it's funny that nested views like sort of had a resurgence lately in the discussion. But this has been in view for quite a while. But I do wanna make you all aware of it. So that if you ever find that you're like, everything else needs to change, or sorry, everything needs to stay the same, except for this one part when the URL swaps, nested views, or nested routes.
[00:07:06] Check this out, this will solve your problems.