Proposal : New component "Include"

[RomainLanz]

Hey there! 👋🏻

I'd like to propose adding a new default component across all Inertia 2 Adapters. This component would replicate a feature I enjoy from unpoly, which allows you to lazy-load a component from another endpoint.

Example

Imagine you have a badge in your website header that indicates whether you are live on Twitch. There are several ways to achieve this:

1. Create an endpoint and have the component poll it (using usePoll).
2. Add the status to your globally shared data.
3. Fetch the status in all controllers and pass it as props (not ideal 😄).

The new component would offer a simpler alternative:

<template>
  <header>
    <h1>My website</h1>
    <Include source="/live" />
  </header>
</template>

How It Works

The Include component would fetch data from the /live endpoint and render the component returned by the server, similar to how a page component works. Additionally, the request will include a special header, X-Inertia-Include: true, so the server knows the request is specifically for an include component and can return different content if needed.

export default class LiveStatusController {
  index({ inertia, request }: HttpContext) {
    if (request.header('X-Inertia-Include')) {
      return inertia.render('includes/live-status')
    }
    
    return inertia.render('live')
  }
}

It will also integrate seamlessly with the WhenVisible component.

<template>
  <article>
    <h2>My article</h2>
    <!-- ... -->
  </article>
  
  <div id="comments">
    <WhenVisible>
        <Include source="/articles/:id/comments" />
    </WhenVisible>
  </div>
</template>

I've got a small proof of concept working in VueJS and AdonisJS, and I can share it later if needed.

[danmatthews]

Oh that's very interesting.

I'd be interested to see how this manages state, as well as managing state at the parent level - where the props for that component etc are kept, how this would work with things like state restoration, scroll keeping etc. If it's just a case of a completely new nested component I guess it would handle all that internally?

I have a feeling this is something that could be extremely useful for modals etc, it would reduce the need for an onVisible call that makes requests to the server (as it would just use the new deferred props, or just load them directly with the component).

I like the idea that this could be controlled by the current page state, and indirectly by the URL, rather than something that relies on setting a base URL like how Hybridly handles it, or the Momentum Modal package handles it.

I realise your concept is not limited to modals btw, just an interesting use case that i've encountered personally.

Colour me interested as a concept for sure.

Subcomponents.

One other thing that interests me is the idea that these could be included as "subcomponents" passed to Inertia::render instead, so all the HTTP traffic would still flow from this same route instead.

PS: forgive me here if my vue syntax is rubbish, i use Svelte!

    inertia('Pages/MyPage', [
    'data' => Inertia::defer(fn () => MyModel::all()),
)
->withComponent('size-modal', 'Components/Modal', [
    'sizes' => Inertia::defer(fn () => ClothingSizes::all()),
])

<InertiaComponent key="size-modal" v-slot="{sizes}" on:mounted="sizes = Object.entries(sizes)">
   <select>
    <option v-for="(label, value) in sizes" :value="value">{label}</option>
   </select>
</InertiaComponent>

[RomainLanz]

Yes, modals are handled quite well in Unpoly. It allows a <Link /> to display its content in a modal rather than navigating to a new page.

For example, on this page, clicking "New company" triggers Unpoly to fetch the URL with a specific header, update the browser's URL, and render the content in a modal. If you refresh the page, you'll see you're on the creation page.

This is something that could be achieved with Inertia as well, but it would likely require a proposal to modify the <Link /> component.

I'd be interested to see how this manages state, as well as managing state at the parent level - where the props for that component etc are kept, how this would work with things like state restoration, scroll keeping etc. If it's just a case of a completely new nested component I guess it would handle all that internally?

This is something we have to try, and see how it goes. 😄

[buhrmi]

That's pretty much identical to the Frames component I proposed ages ago: https://github.com/buhrmi/inertia/blob/x/readme.md#frames

[ArthurYdalgo]

This would've been very useful for me many times. I'm sad I never came across it in the docs. (I'm not saying it's not there, just that I probably never noticed/the name never caught my attention enough for me to read it)

[danmatthews]

I think I prefer the proposal framed as <Include> - Frame conflates too heavily with iframe for me, but that's purely subjective on my part, as I think <Include> also conflates too heavily with the include keyword we see in languages.

One thing I would love is NOT having to register another route - that's the beauty of Inertia for me (and even MORE so with the 2.0 release), and if I have to register a route that's only serving a partial, then it becomes useless in itself, unless you have some sort of if/else going in the controller, which isn't very elegant.

I.e. : calling /users/{user}/edit from an include component would just return the edit modal, but opening users/{user}/edit would show a users listing page beneath the modal itself OR just the contents of the modal itself as a 'page'.

I'm working on a package to provide class-like components to Inertia at the moment and it would be so neat if you could pass the class-based component to inertia::render and it lazy loaded it when needed:

inertia('Pages/Show', [
    'edit_modal' => new EditModal(/* You could pass any constructor arguments here to pass info in */),
]);

OR, if you just wanted to do it using a function:

inertia('Pages/Show', [
       'edit_modal' => Inertia::component('Components/EditModal', [
           'user' => Inertia::defer(fn() => $user),
           'lookup_options' => Lookups::userEditFormLookupValues(), // Used to populate select lists etc.
    ]);
]);

Inertia would:

1. Recognise this as a component, and not load the properties by default.
2. Not serialize this into the JSON props.
3. When the <Component name="edit_modal"> component is mounted, it fires all Inertia's usual requests- async thanks to the new 2.0 rewrite.

[buhrmi]

I do hope they add something like this to 2.0, I don't care if it's called Frame or Include. I just want to stop using my own fork and switch back to something official 😆

[danmatthews]

I'll wait until 2.0 is out, and i'll put something together in a PR I think.

[PedroAugustoRamalhoDuarte]

This feature is very useful. I came from Hotwired and I miss the idea of turbo-frames a little bit. I think we should be inspired by the turbo-frame API's lazy-loading and eager-loading: https://turbo.hotwired.dev/reference/frames#lazy-loaded-frame.

For me, like @buhrmi said, I prefer Frame.

[buhrmi]

Screen.Recording.2024-09-17.at.03.42.37.mov

I've been hard at work on my Inertia fork with support for this feature. The possibilities that a Frame/Include component opens up are really amazing and I do hope to see something like this get implemented in an official release.

[buhrmi]

More demos: https://x.com/einbuhrmi/status/1835844702324797930

Please note I'm just spamming this stuff to convince the core team to add this feature to the official adapters.