preload relations when resolving route model bindings

[laylatichy]

so i keep running into this thing where i have a route like /products/{product} and the model gets resolved through a bindable class, but then in the controller i immediately need to call ->load('images', 'tags') because the resource needs those relations. feels kinda wasteful because the model was just fetched 2 lines ago and now we're doing more queries.

i ended up making this attribute thing that goes on the controller method:

#[Preload(param: ProductBySlug::class, relations: ['images', 'tags', 'categories'])]
public function handle(ProductBySlug $product): Response
{
    // product already has images, tags, categories loaded
    return view('products/show', product: new ProductShowResource($product));
}

and then in the resolve method of the bindable class it reads the matched route's handler attributes and chains ->with() on the query before fetching. so instead of select * from products then select * from images where product_id = ? etc, it does the joins upfront.

the way it works is basically:

1. attribute stores which param class it applies to and which relations to load, I imagine this will have to change to pass param name instead of class for cases where people have /categories/parentCategory/subcategories/subCategory and need different prefetching for both
2. when resolve() runs on the bindable, it grabs the current MatchedRoute from the container
3. reads #[Preload] attributes from the route handler
4. filters for ones matching static::class
5. adds ->with(...$relations) to the query

it's not a lot of code honestly. the attribute is like 15 lines and the resolve logic is maybe 20 lines. but it's really nice because you declare what you need right where you need it and the binding does the rest.

i don't know if this is something that would make sense in tempest itself? like maybe on the #[Get] or #[Post] attributes directly, or as a separate attribute like i have it. just thought i'd throw it out there because it saved us a bunch of n+1 queries and it feels like the kind of thing other people would want too.

happy to make a pr if there's interest, i just wanted to check first because i'm not sure if there's a better way to do this that i'm missing or if you already have something planned for this.

[brendt]

attribute stores which param class it applies to and which relations to load, I imagine this will have to change to pass param name instead of class for cases where people have /categories/parentCategory/subcategories/subCategory and need different prefetching for both

Why not attaching the attribute to the parameter itself?

public function handle(
    #[Preload('images', 'tags')] ProductBySlug $product
): Response
{

That being said. I think it's an interesting feature. I assume when you say "when resolve() runs on the bindable" you mean \Tempest\Database\IsDatabaseModel::resolve specifically, since this is a database-specific feature?

it grabs the current MatchedRoute from the container

I assume by using get() ? I'm trying really hard to stay away from service location, as it more tightly couples our components with the Tempest container. I think it shows how the current Bindable interface is lacking.

What I think would be the best approach is if we could have an initializer specifically for bindable models. That would be the right place to read additional data. I don't know if that would work though, since it would collide with the existing RouteBindingInitializer

An alternative could be to add a special case for models directly in RouteBindingInitializer, but that would require us to introduce a dependency between Router and Database, which I don't want.

A final idea is to improve the resolve method to allow for method injection, but that would require the Bindable interface to be changed to an attribute of some sorts (because it would make the parameters of resolve() dynamic). It would probably look something like this:

trait IsDatabaseModel
{
    #[Bindable]
    public static function resolve(MatchedRoute $route): ?self
    {
         // Find the right argument based on type
        // Check for additional attributes, and add the to the query if needed
    }
}

I'm just thinking out loud by the way. I think it would be a nice feature to have, but I'm not sure about the approach yet.

[laylatichy]

Why not attaching the attribute to the parameter itself?

I like that idea ;p

That being said. I think it's an interesting feature. I assume when you say "when resolve() runs on the bindable" you mean \Tempest\Database\IsDatabaseModel::resolve specifically, since this is a database-specific feature?

yes, i have my own fork of isdbmodel on top of tempest isdbmodel because I added sticky db and a few other things like history tracking for models
and for some models I resolve by different columns, depending on context, for example product by default resolves by id when in admin dashboard context, but then by slug if its store related context so I just have poor man child models looking like this

#[Table(name: 'products')]
final class ProductBySlug extends Product implements Bindable {
    use ResolveModelByColumn;

    protected static function column(): string {
        return 'slug';
    }

    protected static function is_valid(): Closure {
        return is_string(...);
    }
}

ResolveModelByColumn does validation, prefetching if I added attribute by using get() and grabs matched route, but if it was part of the tempest itself we could easily pass relations into resolve second param handle it by default in isdbmodel and if user wants something different then they can define their bindable etc

public static function resolve(MatchedRoute $route): ?self

yeah could be as well

[Nielsen642]

Hi Brent, I came your project on gitHub and found it really interesting.
I am developer working with php and I'd love to contribute
Would you be open to collaboration?