Along with the bugs that you reported, there were also a number of suggestions for code improvements, some of which I didn't even know about, so I've learned a lot from this as well. Thank you very much. They won't take long to implement, so we'll do it now. The first tweak is to update our post show page with a canonical URL inside the head. What does that mean? Well, let's take another look at Stack Overflow, which is what we were using to implement our little pretty URL with self-healing capabilities. And inside the head component here, here we go, link canonical, they have this little

little pretty URL with self-healing capabilities. And inside the head component here, here we go, link canonical, they have this little meta tag that will inform search engines of the correct URL for this page. So let me show you. If I go ahead and add a query string, foo equals bar. Of course, it's going to load the same page here. But if we take a look in the head and find that canonical URL again, notice it doesn't include the query string. So this helps search engines to group similar pages together to help them understand that they are, in fact, the same article, and it will show the correct URL on Google search.

So this helps search engines to group similar pages together to help them understand that they are, in fact, the same article, and it will show the correct URL on Google search results, for example. So let's go ahead and implement that for our post show page. Inertia ships with a cool little Head component that I can use for this. It's not finding it by default, so we'll have to import that manually. Here we go. We'll import Head from inertiajs/vue v3, and now we can make use of it. So in here, we can insert anything that we would usually insert into the HTML head, and it will automatically be pushed into the head by Inertia when this component loads.

So in here, we can insert anything that we would usually insert into the HTML head, and it will automatically be pushed into the head by Inertia when this component loads. So we can say we want a link, the relationship is canonical, and the href, well, we already have the correct prop, which is the post, then we can use route.show, which if you remember, and I'll just open up the Post resource to jog your memory, we added just here. So routes is an array, and inside that routes, we have show, which correctly loads the show route. So we can add that. We can close this link, and then let's go to the front end. We'll head into our application, our refresh.

We can close this link, and then let's go to the front end. We'll head into our application, our refresh. We can open up our elements browser, and inside head, yeah, here we go. We have rel equals canonical, and there's the href for our post. If we go ahead and change maybe the page, note that we have page equals 1 inside the URL, but our canonical link remains the same. So search engines will be able to see that, yeah, there are slight differences here, but they actually basically reference the same page. So I'm just going to show the canonical URL instead. One little thing to keep in mind, Inertia is obviously a client side rendered application.

So I'm just going to show the canonical URL instead. One little thing to keep in mind, Inertia is obviously a client side rendered application. We are rendering in view on the client side. So some search engine crawlers will struggle with that. You may well want to go ahead and turn on server side rendering for Inertia when you deploy your application. If you're using Forge, that literally couldn't be easier. There is a toggle check box on the Forge dashboard. You click it. It turns on server side rendering, and you can basically turn it on and forget it.

You click it. It turns on server side rendering, and you can basically turn it on and forget it. It's such a cool integration. But yeah, if you're not using Forge, read through the docs just so you understand what's going on here. It's pretty straightforward. You just have to make sure you have Node.js set up on the server. You're good to go. Okay? Okay.

Okay? Okay. Our second tweak is with relative dates in our application. So there are a number of places where we say 11 days ago, or for example, in our comments, 10 days ago. And currently, if we go into our IDE, and I do a search for ago, and I'll file mask by view. Yeah, here we go, for example, relative date, and we're manually adding the word ago. We're doing that work manually. However, it was brought to my attention that the formatDistance function from the date

We're doing that work manually. However, it was brought to my attention that the formatDistance function from the date-fns package actually accepts a third argument, which is an object, and that object has a key addSuffix that we can set to true. And if we do that, let's jump back to the front end, note now that the date-fns package is actually automatically adding that suffix for us. Isn't that cool? So with that in mind, we can go back to our code. We can find any instances where we've manually added the word ago, and we can remove them. So there, for example, postIndex, we can get rid of that one as well.

We can find any instances where we've manually added the word ago, and we can remove them. So there, for example, post index, we can get rid of that one as well. And then finally, post show, we can get rid of that one. And now we're letting the date functions package do the work for us. The results are the same, but it's just a little bit cleaner. Great improvement. Our final improvement is to do with the usage of whenLoaded in the various resources we have in our app. If you remember, we're using whenLoaded so that we don't lazy load any data. If we don't eager load the data for User, in this case, for example, on a Post, then

If you remember, we're using whenLoaded so that we don't lazy load any data. If we don't eager load the data for User, in this case, for example, on a Post, then the User won't be included in the data passed down to the front end. There's nothing wrong with how we've done things here, but there is a cleaner way to declare this that I didn't know about. So let's go ahead and refactor. Let's select both the User and Topic lines, and I want to cut out this whenLoaded User and this whenLoaded Topic. I want to remove the shorthand closure. Then I want to remove the parameter we've passed to the make method, and I'll paste

I want to remove the shorthand closure. Then I want to remove the parameter we've passed to the make method, and I'll paste in that when loadedUser and when loadedTopic call. This new syntax is exactly the same, but I'm sure you'd agree it is so much cleaner. I really like it, and I didn't know this was possible, so I've definitely learned something from the process of this course. Let's take a look at our Comment resource. Do we have something similar? Yes, we do. So we can do the same thing.

Yes, we do. So we can do the same thing. Select both of these lines. We'll cut out when loaded. We'll get rid of the shorthand closure. We'll jump to the end, remove the parameter to make, and then paste in this when loaded again. We end up with our nice short syntax. Topic resource? No, no need to worry there.

Topic resource? No, no need to worry there. User resource? Yep, no need to worry there either. So there we are. Small tweaks for sure, but tweaks that I think improve the maintainability, readability, and durability of our code going forwards, which can never be a bad thing.