You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is useful, if you would like to refer to models by their UUID instead of id, for example.
Ziggy currently has the ability to feed an object to the route() helper, which will automatically access object.id if it is present so that the route will autotically receive this argument as well.
Suggestion
It would be great if there were some way to check the return value of getRouteKeyName() to determine the route key that is needed to fulfil the route expectations, instead of referring to .id.
The text was updated successfully, but these errors were encountered:
This is a really cool idea, feels like an extension of #307. One thing I'm hesitant about is that right now Ziggy doesn't actually know when something is a 'model', it's just naively checking for an id key on the object. I would want to make sure that if the route key name is something pretty generic like slug, it doesn't accidentally apply to other routes using different model bindings if we pass an object that also has that key.
Also, I suspect it might be hard to get the route key name info, I'm not certain when it's resolved but if it's not available until the request is being handled, that's probably too late for Ziggy.
Would love to see a PR for this! And otherwise I'll take a stab at it when I have time 😊
Description
Laravel has the ability to return a value other than
id
as the route key name using thegetRouteKeyName
method on an Eloquent model. (See https://laravel.com/docs/7.x/routing#implicit-binding)This is useful, if you would like to refer to models by their UUID instead of id, for example.
Ziggy currently has the ability to feed an object to the
route()
helper, which will automatically accessobject.id
if it is present so that the route will autotically receive this argument as well.Suggestion
It would be great if there were some way to check the return value of
getRouteKeyName()
to determine the route key that is needed to fulfil the route expectations, instead of referring to.id
.The text was updated successfully, but these errors were encountered: