Alright, check this out, I think you're going to like it. If I visit my routes file, and we scroll down to the route for a single post, right now we capture the ID as a wildcard, that is then passed to this callback function, and then we send it to the findOrFail method on your post model. But wouldn't it be cool if Laravel just knew, well, you probably want a post with the given ID, and then we could pass that post like so. It would be nice. But if we take a look at Firefox, and we load a page... wait a minute, that does work. Exactly what we had before... which, at first, doesn't make any sense. How on earth does this work? Introducing Route Model Binding 0:35Exactly what we had before... which, at first, doesn't make any sense. How on earth does this work? Well, it's not overly complicated. It's a concept known as route model binding. You are binding a route key to an underlying Eloquent model. Route model binding. Now there are a couple things to be aware of. First, your wildcard name has to match up with the variable name here. So for example, if I change this to foo, it's not going to work anymore. So that is something to be aware of.So for example, if I change this to foo, it's not going to work anymore. So that is something to be aware of. So basically what's going on behind the scenes is when you type hint post here, Laravel's then going to figure out if your variable name matches up with the wildcard name. And if it does, it's smart enough to know, okay, you're probably trying to find the corresponding post. So it's going to figure out what the default key that represents a post is, and by default that's always id, and it will effectively say, okay, find the post with the given id. It'll do it for you automatically. And by the way, this particular approach is almost always the one I take. Binding by Slug Setup 1:34It'll do it for you automatically. And by the way, this particular approach is almost always the one I take. Now there will be times, though, when you want to find a post or any Eloquent model not according to its id, but instead some other unique column. Maybe the slug. Why don't we play around with that? Let's go back to my create post table migration, and add a new one here for a slug. It's going to be a string, and it should be unique. Okay, so let's go ahead and run migrate fresh. Drop the tables and rerun them.Okay, so let's go ahead and run migrate fresh. Drop the tables and rerun them. Okay, so now back in TablePlus, if I give this a refresh, actually before I do, I'm going to copy all of this as an insert statement. But if I give it a refresh with Command-R, they're now gone, but I do have a corresponding slug. Okay, so let's just bring it back, but I will need to add a slug for each. My first post... Command-Enter to run that, and... whoops. Alright, one more time. Using Slug in Routes 2:37Command-Enter to run that, and... whoops. Alright, one more time. Command-Enter to run that, and we should be back up and running. But now each post has a corresponding slug. Okay, so now we're going to use the slug to identify the post. And here's how. If I come back to my routes file, we're now going to say, okay, I want you to find the post not according to an ID, but instead a slug. So I can say colon slug. Now effectively, behind the scenes, Laravel will do something resembling, give me theSo I can say colon slug. Now effectively, behind the scenes, Laravel will do something resembling, give me the post where the slug matches the slug you provide, the wildcard here, and then give me the first result. Or actually more like first or fail. That's effectively what's happening here. So let's give it a shot. But before we do, let's quickly go to our post overview page, and now we're not going to include the ID, it will actually be the slug of the post. Okay, let's give it a shot.to include the ID, it will actually be the slug of the post. Okay, let's give it a shot. Give it a refresh, and now we've found the post. Notice the slug is represented in the URI, and yet the route model binding still works as expected. But if we try to access anything that doesn't exist, of course we get a 404, and that's what we want. So do notice if we come back to our routes file, if we did not have this, yeah, again, Laravel is going to find the post with the given ID, but we don't have an ID in the URI anymore. Overriding Route Key Name 4:03Laravel is going to find the post with the given ID, but we don't have an ID in the URI anymore. We have a slug. So you would get a 404 in that case. Okay, so that's one way to do it. Another option, if a slug will always be the identifier to finding a post, you could alternatively say, go to my post model, and you're going to add this new method here. I'll override it. It's called, I often forget, routeKeyName. This should return the name of the key, or the attribute, that you should find the postIt's called, I often forget, routeKeyName. This should return the name of the key, or the attribute, that you should find the post according to. So in our case, the attribute in the database was called slug. Okay, so this would be an alternative option. Notice back in my routes file, we have it just like we did before, but this time, it'll work. So which path you take, like always, is entirely up to you. And in fact, this option you see here, for a long time in Laravel, was the only way to accomplish this. Choosing the Best Approach 4:54And in fact, this option you see here, for a long time in Laravel, was the only way to accomplish this. It's only relatively recently that support for specifying the key as part of the URI was introduced. So generally, if this is the only place where I would need to declare that data, I'm just going to keep it directly in the route. On the other hand, if you have many routes and many extensions of this URI, where you'll need to find a post according to the slug, you might want to throw it on the post model. But my recommendation is start with the simple approach here.But my recommendation is start with the simple approach here.
