Feature request: Allow Concurrent Partial Reloads with "only"

[rickbairstow]

Hey 👋

We're using InertiaJS with Vue3 for our admin panel, which has several pages containing hefty amounts of data and graphs. We're diving into partial reloads to implement lazy loading when users scroll near relevant content. However, we've noticed a limitation: its not possible to do concurrent partial reloads using the "only" flag.

Inertia's feature of canceling previous requests is great and very intentional, it's been super helpful for most of our use cases so far. But isn't ideal for our larger pages where we require multiple sections' data to be lazy loaded using partial reloads. So far we've been bundling them together with only: ['a', 'b', 'c'] but its not ideal for lazy content at that magnitude.

We're working on a feature that uses a scroll observer to trigger partial reloads for lazy data. For simplicity, let's look at this from an Vue onMounted example:

import { router } from '@inertiajs/vue3'

onMounted = () => {
  router.reload({ only: ['chartA'] })
  router.reload({ only: ['chartB'] })
  router.reload({ only: ['chartC'] })
}

We'd like to be able to run these requests simultaneously without canceling each other out, specifically when using "only", and ensure we can access all the resulting data in our Vue components.

We're interested in InertiaJS supporting concurrent partial reloads with the "only" flag. This enhancement could offer greater control over lazy loading content, especially beneficial for larger applications. Additionally, it would streamline the creation of position observers to trigger lazy loading, making it more practical and accessible for everyone.

Thanks,
Rick

[actengage]

Thank you very much for bringing up this issue. I want to post here and hopefully bring some attention to this since there are no comments. This doesn't even feel like a feature request, but a bug. It feels fundamentally broken for Inertia to do this. It requires us to use JSON/api endpoints to load things for metrics and data intensive requests. Inertia is pitched as a way to "build an app without an API" but this is pretty good example of how that's not even possible.

For example I have a details page that loads a model, but if that model has 2 relationships I want to load into their own data tables with search fields, pagination, etc. I actually used this post to figure out why one would load, but the first request was cancelled. I don't even remotely understand how this is good behavior. In a standard SPA I can load everything concurrently.

In summary, lazy loading should be just that and not force me to load multiple lazy loaded collections at the same time. Furthermore, this limitation isn't even mentioned in the documentation. And if it is, forgive me for missing it in the docs. This is a pretty big deal breaker for us that I feel should be getting much more attention.

[rickbairstow]

I forked it to play around a little and managed to get concurrent requests working easily enough. But it seems Inertia takes a snapshot of all the props when the request fires, does what it needs to, then fully replaces them. So multiple lazy requests would cause chaos. I didn't delve beyond this as I figured it'd be a domino effect of implementing one thing and potentially breaking more at Inertia's core.

[actengage]

Thanks for confirming that. That's about what I gathered too. We've gone back and forth with API and Inertia responses. It's pretty frustrating that Inertia partial reloads won't scale. I really hate to maintain API routes for certain things and break the consistency of the entire for seems like should be possible by the core library. I wish we could get some input from the maintainers on this.

[adamalbrecht]

We are also running into this limitation. @rickbairstow @actengage have you come up with any better solutions?

[rickbairstow]

I don't have any solutions for this. My use case is an internal system so we chose to accept the limitation, but our future projects will require better lazy loading and will either end up with us not using Inertia, or building our own lazy data loader of some kind.

[actengage]

I am in the same boat as @rickbairstow. We have chose to accept this limitation and shipped this into production. That said, I dont see real measurable performance hits as a result. Some pages have 5-6 requests that get cancelled and its only the last request that delivers all the data. I have forked the repo with the intent on finding a real solution, but do to time and project constraints I haven't had time to actually invest in solving this issue.