On most websites, you'll see content that follows the same structure over and over again, just with different content. For instance, a blog with lots of posts or an e-commerce site with lots of products. A travel app is no different. Each destination consists of the same type of info, like an image, a name, a description, and a collection of excursions or experiences, just with different values for each destination.
We could create a new file for every new destination, like we have already, but this will quickly become hard to maintain on any website of scale. There is a better way. It's called route parameters or params. What is a route param?
The easiest way to understand it is for me to show you. So, let's set up a route with a param in it. In router slash index dot js, let's create a new route. The path for this route will be slash destination slash colon id.
Notice the colon here. This is how we define route params with Vue Router. It's kind of like a wildcard that says you can put anything you want in this part of the path and it will be accessible via a variable named ID. This route will have to point to a particular component.
Let's point it to a component we'll make in just a second called destination show. All right, let's create the destination show page. We'll add an h two tag and some text that says hello destination. Let me make sure I've saved my index file.
All right. Now if we visit destination slash, well, anything in our browser, we can see our page. Notice you can change out the last part of the URL path. And no matter what we change it to, we still arrive at the same page.
That's kind of cool, but not very useful. Let's access that route param ID and use it to display the proper destinations details. But how do we access the value of that ID param? Let me show you something really quick in the dev tools.
If we click on app, you see that we have this special route property. If we inspect that, you can see that we have access to not just the path and the name, but also params, query, and meta. params in any component since it's made globally for our view app instance. Let's give it a try in the destination show page.
Inside of the H two, we can print out the ID. Great, now we've got access to that ID param. Let's use the ID to find our destination. id.
I'm also going to use the parse int function to coerce our destination ID to an integer or number. This is necessary because any param coming from the URL is actually a string, even though our IDs look like a number. When we do a comparison in a minute to match the ID to the destination, it will be important for the ID to be the proper type. Great, now the destination ID is available via our computed prop.
While it is not actually necessary to create a computed prop to get what we want, it will make it a little easier to follow what's going on in our code. json file. json. Now we can create a computed property and use the JavaScript function find to look through all the destinations and return the one that has an ID matching the ID from our route params.
For the callback function that I'm passing to find, I'm using the shorthand of the JavaScript error function by leaving off the surrounding curly braces and keeping the entire function on a single line. This keeps me from having to provide the return keyword and just keeps things short and sweet. We can use the triple equals or strict comparison here because we used the parse int above. Now in our template, we can add the destination name, the description, and the photos.
Now, if we take a look at our application's destination show page in the browser, with the param ID of one in the URL, you'll see the details for the Brazil destination. When we change the URL param to two, we see the Panama details, and so on. We can also see in the dev tools, under the route option, that every time we visit a different route, we can see what the path is, the params ID, and the name of the component, which is destination show. Looks good so far.