Our app is looking good, but we can make it even better. We are using IDs for our details, but wouldn't it be better if we could see the name of the destination in the URL instead of an ID? Let's do it. js file, let's change the params from ID to slug.
Now in our destination details page, we need to change the destination ID to slug and the ID to slug2. slug and change our params to also be slug instead of id. slug. We need to do the same in our navigation component and we can delete the destination id in our data as we're not using that.
Now if we look at our application and test it out we can see that changing the routes now gives us the name of the destination instead of the id. But did you notice the hash symbol before the word details? The default mode for ViewRouter is HashMode. It uses the URL hash to simulate a full URL so that the page won't be reloaded when the URL changes.
That's great, but a little ugly. pushState API to achieve URL navigation without a page reload. js file, we just need to add mode history. When using history mode, the URL will look normal.
Let's check it out and see. Beautiful. No more hash. Using $root in your component creates a tight coupling with the root, which limits the flexibility of the component as it can only be used on certain URLs.
To decouple this component from the router, we can use props. Let's refactor our app to use props instead of the root. js file, let's add the props property with the value of true to each of our roots. Then in our destination details page, let's add our props.
We add a props property and inside it add the slug property, which is our slug params. We need to add type of string and we make required to be true as this prop is required for the page to work. We can now delete the data property we have for slug. as we no longer need this as we are now getting this value directly from props.
And as you can see, it still works just like before, but now our component is not tightly coupled with the root. Loosely coupled components gives us better flexibility if business requirements change and we need to restructure our applications. If you think about it, the destination details component does not need to know where it gets its data from. It might be from an input field, the router, or from any other possible source.
No matter where it comes from, the component should always work the same. Our app is looking good, but we can make it even better. We are using IDs for our details, but wouldn't it be better if we could see the name of the destination in the URL instead of an ID? Let's do it.
js file, let's change the params from ID to slug. Now in our destination details page, we need to change the destination ID to slug and the ID to slug2. slug and change our params to also be slug instead of id. slug.
We need to do the same in our navigation component and we can delete the destination id in our data as we're not using that. Now if we look at our application and test it out we can see that changing the routes now gives us the name of the destination instead of the id. But did you notice the hash symbol before the word details? The default mode for ViewRouter is HashMode.
It uses the URL hash to simulate a full URL so that the page won't be reloaded when the URL changes. That's great, but a little ugly. pushState API to achieve URL navigation without a page reload. js file, we just need to add mode history.
When using history mode, the URL will look normal. Let's check it out and see. Beautiful. No more hash.
Using $root in your component creates a tight coupling with the root, which limits the flexibility of the component as it can only be used on certain URLs. To decouple this component from the router, we can use props. Let's refactor our app to use props instead of the root. js file, let's add the props property with the value of true to each of our roots.
Then in our destination details page, let's add our props. We add a props property and inside it add the slug property, which is our slug params. We need to add type of string and we make required to be true as this prop is required for the page to work. We can now delete the data property we have for slug.
as we no longer need this as we are now getting this value directly from props. And as you can see, it still works just like before, but now our component is not tightly coupled with the root. Loosely coupled components gives us better flexibility if business requirements change and we need to restructure our applications. If you think about it, the destination details component does not need to know where it gets its data from.
It might be from an input field, the router, or from any other possible source. No matter where it comes from, the component should always work the same.