Using dollar sign route in your component creates a tight coupling with the route, which limits the flexibility of the component as it can only be used on certain URLs. While this is not necessarily a bad thing, we can decouple this behavior with a props option on our route records for extra flexibility. dollar sign route. js file, let's add the props property with the value of true to our destination show route.
Then, in our destination show page, let's add an ID prop. This prop will correspond directly with the ID param from our route. We need to add the type of string. And we make required be true as this prop is required for the page to work.
We can now delete the computed property we have for destination ID. And then we'll change destination ID here to ID since the route param is named differently than our computed prop was. and call parseInt on it as that disappeared with the computed prop. And as you can see, it still works just like before, but now our component is not so tightly coupled with the route.
It's worth noting the props property on a route record can also contain a value other than a Boolean. you can pass it an object to provide static prop values to your component's prompts. In this case, the Routes component could have a property called NewsletterPopup. And when visited through this route, that props value would always be false.
You can also create a function that receives the route as its argument and returns props. This allows you to cast parameters into other types, combine static values with route-based values, and much more. Take this props function, for example. Our expression here could use any information on the route to determine whether or not the newsletter popup should be true or false.
Let's actually take this opportunity to cast our ID to an integer. Now, in the page component, we don't have to think about the data type. We can remove the parse int from destination show. And we'll make sure to strictly compare these two.
Lastly, we'll change the type from string to number, as it really should be. Everything still works. Loosely coupled components give us greater flexibility if business requirements change and we need to restructure our applications. And that's what route props provide us with.
If you think about it, the destination show component does not need to know where it gets its data from. It might be from an input field. the router, or any other possible source. No matter where it comes from, the component should always work the same.