Nested "pages" in Inertia?

[gilbitron]

I've been searching but can't find a good answer to this. I have an inertia "page" component (1) which can optionally include a side panel component (2). Including the data for the side panel in the Inertia response is not an issue (although #249 would be a nice addition here). My main issue is the nested list component in the side panel (3).

The list can be sorted, items can be added/removed etc. and actions can be performed on the items. At the moment, I'm handling this with a bunch of axios requests to an API backend, like you would in a normal SPA. However, it doesn't feel very "Inertia" and I'm wondering if there is a better way to encapsulate this functionality?

What I'd ideally like is for this component to be it's own Inertia "page" with an Inertia controller dedicated to handling the actions performed on the list component without having to use axios. I'm thinking something along the lines Hotwire Turbo Frames or even just Livewire actions. Any ideas?

[gilbitron]

I've just realised, this is basically the same thing as the partials talked about in #249.

[RobertBoes]

You might be interested in this PR: inertiajs/pingcrm#100
This does take a different approach, without nested pages / partials, but it seems to fit for your use-case

[claudiodekker]

So, here's how I would solve this:

First, I'd treat the entire thing ((1), (2) and (3)) as the "page", meaning that whether I'm viewing the product itself or the products list without the 'overlay'/slide in, I'm using the same Inertia "page component" for it. This might seem somewhat controversial, but because of your 'panelled' design, this really isn't that bad of an approach.

First, I'd define either two routes, or one route with an optional parameter. Note that I'm pointing both to the index action, instead of one to the show action. Of course, you can tweak this as-needed, but it makes explaining this method easier:

Route::get('/products', [ProductsController::class, 'index');
Route::get('/products/{product}', [ProductsController::class, 'index');

Then, in that controller action, I'd pass the products list (for the 1st call) lazily, as well as the product details themselves, which by default (also for the 1st call) will be an empty array that we can use to indicate that there's no displayable product (v-if="product.id"). Something like this:

public function index(Product $product = null) 
{
    return Inertia::render('Products/Show', [
        'products' => fn () => Product::all()->only(['id', 'name']),
        'product' => $product ? [
            'id' => $product->id,
            'uploads' => $product->uploads->map->only(['id', 'size', 'name', 'preview_url']),
        ] : [],
    ]);
}

Then, for the <inertia-link>s to your products (inside (1)), I'd use the partial reloads feature to only re-fetch the product itself:

<inertia-link v-for="product in products" :key="product.id" :href="`/products/${product.id}`" :only="['product']">{{ product.name }}</inertia-link>

Now, as you click that link, the request will respond with the same page component that we're already on, but because we're only requesting the product, the lazily-evaluated products callback ('products' => fn () => ...) and all related calls (e.g. to the database) won't get executed, with only the product prop being returned & updated on the client-side.

Finally, the update of the product prop will trigger Vue to re-render (a part of) the page that will then allow your v-if="product.id" to successfully evaluate, allowing you to display/transition in your 'product' panel (2).

As for uploads themselves (3), I'd essentially make this behave the same way as the 'links', but then using either the form helper or a manual visit.

Hope this helps!

[gilbitron]

Thanks for the suggestion. What you've described it pretty much how I've implemented parts 1 & 2 already. It's really the list component (3) that I need help with. For example, how would I add/remove/sort a list like that without affecting the product panel (2)?

[claudiodekker]

You'd use the same technique as with the products: Make your post/put/patch call that creates or modifies the uploads on the back-end, and then redirect back to the 'view product' page.

As for sorting, that should also happen on the back-end. If you have a drag-and-droppable sorting order, I'd recommend doing what Jira does with their 'LexoRank' approach: https://www.youtube.com/watch?v=OjQv9xMoFbg