What is the best method to request data from another CRUD?

[zorca]

In Inertia, we request data about companies on the companies page. But what if we need to link contacts from another CRUD to the company? For example, we want to search for existing contacts using the searchable select field and insert the found contact into the company creation form. With the usual API, we make a request to another endpoint. In the case of Intertia, such a GET request leads to the opening of the page. I'm using Laravel + Vue.

[sneakylenny]

[claudiodekker]

Yeah, that's totally a realistic risk. I wouldn't want to load details that you aren't for sure going to use, as it's less than ideal from all kinds of aspects (database, browser memory usage, data transfer size, etc.)

Your idea of enriching the Inertia page with Axios data isn't a bad idea at all, but instead of trying to manipulate/repopulate the props, what I'd do is this:

• Create a data attribute into which you 'load' the data at some point using the Axios request.
• Create a computed property, and in there combine the page.props entry with the data entry. Whenever the Axios request fills this data attribute, this will then automatically update this property, which is essentially the same as the 'updated' prop you're looking for. You can then just use this in your views instead.
• Finally, to solve the issue of history navigation, I'd use remember on this data attribute, but as you can see this does fairly complex fairly quickly.

Alternatively, and what I would probably go for, is to loop over your loaded phone numbers on the back-end, and 'map' them into lazy props that you then assign to a (predictable) key in your Inertia render call (such as the phone number itself). Then, you can use only to conditionally load in those specific keys. That way, you only send the data to the client when they ask for it, and you don't need to do and combining/use any computed props on the client side. Something like this:

$mappedLazyProps = $phone->theDataForExample()
    ->get()
    ->mapWithKeys(fn ($item) => [
        $item->myPredictableKey => Inertia::lazy(fn () => $item))
    ]);

return Inertia::render('Phone/PhoneNumber', array_merge(
    $mappedLazyProps,
    [
        'somePageProp' => 'value',
    ], 
));

Furthermore, to prevent the need to load all entries from the database, you could also observe the request for the header used by Inertia's only, so you know when the request hits / before the response is returned which phone numbers are being loaded. This should allow you to conditionally scope your database query:

$mappedLazyProps = $phone->theDataForExample()
    ->when(Request::header('X-Inertia-Partial-Data'), function ($query, $header) {
        $query->whereIn('phone_number', explode(',', $header));
    })
    ->get()
    ->mapWithKeys(fn ($item) => [
        $item['phone_number'] => Inertia::lazy(fn () => $item))
    ]);

return Inertia::render('Phone/PhoneNumber', array_merge(
    $mappedLazyProps,
    [
        'somePageProp' => 'value',
    ], 
));

Keep in mind that the above is overly simplistic and still has all kinds of issues (it'd still fetch EVERYTHING if you're not making an only-request, as well as that it passes ALL only fields to the query instead of only the phone numbers), but conceptually I believe it's fairly solid.

[claudiodekker]

Since there seems to be a realistic use-case, I'd say that you could expect that at some point, yes.

I can't promise anything regarding a 'when' or what a solution to this problem would exactly look like (it could take many months and end up looking very different from what I suggested above), but whenever we have some time we're generally constantly doing the best we can to think of and implement ideas that improves Inertia for everyone.

The reason why I say this, is because there's a lot of issues/unsolved challenges left for Inertia as-is, and at least from my perspective, this specific one is (as of now, at least) less common/smaller than some of the others. Especially if you consider the workarounds that are possible (such as the ones I mentioned in my previous comment).

That said, since Inertia is open-source, there's nothing preventing you from proposing an idea/approach to solving this, or from creating your own package to do so. If we see that such an idea/package takes off and lots of people want it for realistic reasons, and perhaps even more importantly, if we believe it makes sense to us to be part of the core without over-complicating things, then that definitely goes a long end to us actually implementing the feature sooner rather than later.

[ajnsn]

Just a quick note @claudiodekker that the main issue here is again (and again)...

It all works fine but it replaces the url :(

Which could be solved by allowing developers to specify the render url.

[claudiodekker]

@ajnsn Right, so, I'm aware of most of the problems that pop up, as well as the suggested/potential solutions such as your PR, but for us, solving a problem goes a lot further than just going over the code, agreeing with what it does and merging it.

To take your solution as an example, while it does look and sound good on first glance, it closely touches the fundamental principles that Inertia is designed around (server-side state for client-side apps), and while that isn't a bad thing per-se, it does raise other questions/concerns:

• Does this actually solve a problem, or does it just shift the problem and cause different ones instead?
• How does this affect the way people will build their apps going forward?
• Will any existing features become irrelevant or confusing, and do they all keep working as intended?

And those are only some of the more obvious concerns that come to mind. There's lots others that are more generic when maintaining any open-source project, like 'is this something we want to maintain going forward, or would we rather provide a different solution?', 'is this something the community actually wants or needs?' etc.

In either case, the very least I'll have to do in order to be convinced that your solution is the right one, is to sit down and to realistically take an hour or more to answer those questions for myself by testing the actual solution. Then, assuming I'm convinced that it is a good solution, I'll have to wait until @reinink has had some time to go over it as well, so that we can compare notes and see if we both agree, and only then it gets merged. This team effort is in part why Inertia feels so polished.

As you can probably imagine, this means that some things are easier to get merged as others, and since the possible implications of a feature such as this one are pretty large, it simply means that it takes us longer to even get around to reviewing, especially if we're both busy with our own respective businesses. After all, Inertia is an open-source project that we unfortunately aren't able to go full-time on at this point in time, and as of late we've unfortunately been really busy.

Anyway, even without properly going through the feature/PR yet, there are some preliminary concerns that I have, but I won't know whether they're valid concerns until I go through the feature myself, so that's why I haven't commented them on your PR yet (I don't want to waste a contributors time with questions that I can just answer for myself if I simply go ahead and take the time that I need to take anyway in order to approve the PR):

• Yes, it sounds nice to 'spoof' the URL, but what if someone were to 'reload' the page / visit that URL directly? Will they end up with (more or less) the same representation of that page, or could it potentially be an entirely different page? And if so, do we want to support that behaviour... is that really a good idea?
• There are features such as the location visit, replace state, "reload" visit and possibly others that rely on the current URL to function correctly. Are we sure those won't break? Because it seems pretty plausible to me that they might behave 'odd' when spoofing the URL.

Anyway, this message ended up way longer than intended, but I hope this helps explaining some part of the process and considerations we use to get things into Inertia. To put it simple, it's not actually all that simple.

Hope this helps, and thanks again for contributing to Inertia 👍

[ajnsn]

Thanks @claudiodekker for the comprehensive response. I really do understand all the side effects and implications. This is just an option and it's not enabled by default.

Your users are not end users, they are developers. And developers need options, different approaches. Maybe in just this one case, this option is the right one. It doesn't matter if it works in any case or with other options. This is also not the case with Laravel or comparable "hybrid" approaches like Livewire.

We are able to move this project forward by trying options and approaches, especially as it's not stable yet. But not being able to return something when posting data is somehow a huge stop sign for me. And i see other developers here struggling with this. Currently I am able to work around with my own fork but definitetly this needs some more attention 👍

In any case, thank you and @reinink for all your hard work you put in Inertia.