Streamed Deferred Props

[nick-potts]

I've been wondering what Promises would look like as props in Inertia, and I have a partial solution so far. I think this general idea would help move Inertia towards a place where it's more ready for some of the newer JS concepts like React/Vue Suspense. It'd also hand the control over to the developer in terms of how fast a page can be loaded. If there's any sort of heavy function that needs calling, this could instead be deferred and and the frontend could handle the wait, instead of blocking the entire page navigation.

In terms of what it would look like, I'm thinking end goal you'd be able to do something like this

Inertia::render('View', [
    'data' => 'fast_data',
    'slow_data' => Inertia::defer(fn() => resolvesAfterInitialResponse())
]);

Then on the client side, the data would look like this

interface ViewProps {
    data: string,
    slow_data: Promise<string>
}

Then it'd be trivial to use something like React Suspense

<div>
  <div>{data}</div>
  <Suspense fallback={<div>Loading...</div>}>
    <SlowDataComponent slow_data={slow_data} />
  </Suspense>
</div>

Obviously this would require a fairly different setup to what is currently implemented.

On the PHP side, things can get a bit tricky and there's a few ways of tackling it. I was initially thinking that if there's a deferred prop, it could get passed with a flag indicating so:

{
   "data":"hi",
   "slow_data":{
      "__deferred__":true
   }
}

Then there's probably two ways to tackle it. First would be the boring route, where inertia does a second request and this data can be streamed in via json:

if ($request->header(Header::INERTIA_DEFERRED)) {
    $response = new StreamedResponse(function () use ($page, $props) {
        // maybe include page props initially

        foreach ($this->resolveDeferredProps($props) as $key => $value) {
            echo json_encode([$key => $value]);
            ob_flush();
            flush();
        }
    });

    $response->headers->set('Content-Type', 'application/json');
    $response->headers->set(Header::INERTIA_DEFERRED, 'true');

    return $response;
}

The second, more exciting way, would be to do the entire thing in one response. Not sure how this would work, but I'd imagine you resolve each prop and fire an event Inertia can listen for, and that would allow the promise to get resolved:

// Emit an event with the deferred props
echo '<script>window.dispatchEvent(new CustomEvent("deferredProps", { detail: ' . json_encode($deferredProps) . ' }));</script>';
flush();
ob_flush();

With subsequent page loads, things are far more simple and it would just be a matter of flushing the page props, then each deferred prop out.

I'd also like to see an adapter of some sort for the deferred props. Basically allow the user to provide different strategies for how the ordering of the prop data is rendered out. This would allow for someone to wait for all deferred prop data in one go. Or each prop sequentially, or each prop but in some sort of specified order. Or in my case, I'd like to run each prop resolver using ReactPhp's async function and resolve it with whatever comes back first.

This would handle the CSR case, and then for server it'd require a new server that's different to the SSR server, as it'd need to use the renderToPipeableStream.

[nick-potts]

Or perhaps a cleaner solution is that CSR only apps run like normal and automatically fetch deferred props after load, whereas the Streamed Server implementation uses the whole shebang.

[nick-potts]

After digging through the internals, I can see that supporting renderToPipeableStream would be quite a mission from Inertia's side since laravel ViewResponse would have to support streaming. With some tinkering, I think this would still be possible but perhaps not best suited to inertia.