Summary

@hono/inertia currently implements the core of the Inertia protocol (the page
object, asset versioning with 409 reloads, and the XHR/JSON/HTML response
split). The next layer of the protocol — partial reloads, deferred props,
merge props, and infinite scroll — isn't covered yet.

I'd like to contribute these upstream, but since they're a connected set of
features (and partly depend on each other), I wanted to open an issue first to
align on direction before sending PRs.

Background

While building a small SaaS-style app (a Todo app on Hono + Inertia + hono/jsx,
SSR), I needed these features and implemented them in a protocol-compatible fork,
@ashunar0/hono-inertia-plus, which I've been dogfooding. The API stays close to
the current c.render:

import { inertiaPlus, defer, scroll } from '@ashunar0/hono-inertia-plus'

app.use(inertiaPlus())

app.get('/', (c) =>
  c.render('Home', {
    // deferred: resolver is skipped on the initial response, advertised via
    // page.deferredProps, then fetched by the client's <Deferred> as a partial reload
    tasks: defer(() => db.tasks.list(userId)),
  })
)

What I've verified end-to-end in that app:

• Partial reloads (only / except) — router.reload({ only: ['tasks'] })
• Deferred props — defer(() => ...) + <Deferred> (shown above)
• Merge props & Infinite scroll — scroll({ ... }) emits
  page.scrollProps / mergeProps for Inertia v3's <InfiniteScroll>

All four run through a single renderer, mirroring how the Laravel/Rails adapters
layer these on top of the same partial-reload machinery. Source:
https://github.com/ashunar0/hono-playground/blob/main/packages/hono-inertia-plus/src/index.ts

Proposed plan

These have a natural dependency order, so I'd send them as separate, reviewable
PRs rather than one big one:

① partial reloads (only / except)   ← foundation
   ├─ ② deferred props               ← builds on ①
   └─ ③ merge props                  ← builds on ①
         └─ ④ infinite scroll        ← builds on ① + ③

① is the foundation: it reads X-Inertia-Partial-Component /
X-Inertia-Partial-Data / X-Inertia-Partial-Except and filters props
accordingly. The other three advertise extra fields on the page object that the
client adapter reads.

Questions

1. Is adding these to @hono/inertia in scope, or would you prefer the adapter
   stay minimal and leave advanced features to userland?
2. If in scope, is the incremental PR breakdown above reasonable, or would you
   rather review it differently?

Happy to start with ① once there's a thumbs-up on the direction. Thanks for
maintaining this! 🙏