Using multiple keys for route model binding
Playing
01. Using multiple keys for route model binding

Episodes

0%
Your progress
  • Total: 4m
  • Played: 0m
  • Remaining: 4m
Join or sign in to track your progress

Transcript

00:00
So I've recently found myself needing to access items like courses in a URL using root model binding by both the slug and the ID as well. So for whatever reason, if you are needing to do this or if you do need to do this in the future, I'm going to show you exactly how we do that now.
00:20
So I've already got a model created and a migration created with a slug and of course an ID. Let's come over to the browser and just hit the URL slash 1. This is default root model binding.
00:32
It will look this up by the primary key. But of course if we try and use some course just inside of here, which was that slug, of course we're going to get an invalid text representation in our database because it's trying to pass a string value into the database to look up a integer.
00:49
So of course that is a problem. Now of course what we can do is modify the behavior of root model binding. So what we can do in Laravel is modify how something is looked up. There's a couple of ways to do this.
01:03
The first one is to come over to the model and introduce a get root key name method. But that doesn't really solve our problem. That just goes ahead and switches this over to choose which column to look this up by. So in this case that is now going to work.
01:19
But of course we're back to square one where the ID lookup isn't going to work. So how do we do this? Well, we're not going to do this inside of the model. We're going to come straight over to our providers, over to root service provider.
01:31
Of course what you can do is register a new provider for these bindings as well if you want. So to customize the logic here, it's pretty straightforward. We just use root bind.
01:43
We give the name of the model, the singular version, and then we go ahead and give in a closure. So let's do this now. And from that we'll actually get the value inside of here.
01:53
So if you didn't know how to do that, you do now. You can create your own logic in here to look this up. So if I just give that a refresh, you can see we get the actual value here. And sure enough, if we give one in here, that's going to work as well.
02:06
Now really important that we do this because one has been passed down as a string and not an actual integer. So when we are doing this custom lookup, we need to make sure that we are checking if this is numeric, not if it's actually an integer within PHP.
02:21
So what we're going to do is return. And let's just kind of duplicate or replicate rather the default behavior here. This would be where slug equals the value. And then a really good idea here is to do first or fail.
02:35
So this fails and Laravel generates a 404 page. So if we of course just pull in the model there, give that a refresh, that's not working because we're looking this up by the slug. And if we go ahead and say some course, then that works as normal.
02:49
So what we want to do is just get rid of first or fail for now and we want to introduce an or where clause on to this. And this will have its own closure where we'll get through a builder. So this will be a query builder.
03:02
You can call this builder or query, it doesn't really matter. And let's go ahead and pull the value just into scope here. And let's go ahead and check this value if it's numeric. Like I said, that's really important.
03:15
You don't want to check if this is an integer because of course it's not, it's been passed down as a string. Of course the alternative here would be to cast it just up here to an integer but I much prefer just using is numeric.
03:26
I found this works a little bit better. So let's go ahead and pass the value in here. So if this is numeric, what we're going to do is using the query builder, we're going to override the where and we're going to say where the ID equals that value.
03:39
And of course you can customize this to make this a bit more powerful depending on how you want to look things up. I found this just works very nicely. So to top this off, we're just going to say first or fail just at the end of here after
03:52
the or where clause. Give that a refresh. That still works. And when we go ahead and hit this by the ID, that also works as well.
04:01
So there we go. Really simple tip. Just customizing our logic here to check if we have a numeric value in and going ahead looking this up by the primary key.

Episode summary

In this episode, we dive into a really practical Laravel tip: how to set up route model binding so it works with either an ID or a slug in your URLs. This means users (or your app) can visit a route like /courses/1 or /courses/some-slug and get the same resource, whether they use the numeric ID or a readable string slug.

We start out by looking at the default route model binding behavior—in Laravel, it looks up a model using the primary key (usually the ID). That's fine, but it breaks when you try to pass a slug instead, because Laravel expects an integer.

First, we check out overriding the getRouteKeyName() method on the model, but that just swaps between ID and slug—doesn't help if you want to support both.

The real solution? We jump into the RouteServiceProvider and set up a custom binding closure. Inside, we add some logic: if the incoming value is numeric, search by ID; otherwise, search by slug. We also look at using firstOrFail() to keep things tidy and ensure the app returns a 404 if nothing is found (just like the default model binding).

By the end, you'll see how to make your routes flexible while keeping your code clean and easy to maintain. It's a simple change, but really useful!

Episode discussion

No comments, yet. Be the first!