When should a paginated Inertia.js list use deferred props instead of merge props?

Inertia.js transports page props as JSON and leaves date parsing, time-zone conversion and locale formatting to the backend serializer and the client formatter, so regional date handling is not something the adapter itself decides. A more relevant unresolved question is how deferred props should interact with partial reloads and merge-based pagination.

Deferred props omit a value from the initial page response and fetch it in a follow-up request, optionally grouped so several groups load in parallel. Merge props append list data rather than replacing it, which is what makes infinite-scroll pagination work. A large paginated list could be modeled either way, and the two have different refresh semantics: the choice determines whether later pages append to or overwrite existing data.

Deferred, once, merge and visibility-triggered loading are comparatively recent, and helper names, grouping defaults and reload semantics differ between Inertia major versions and adapters. Deferred props are not automatically re-fetched by a partial reload, and Inertia filters only top-level page props, so nested keys cannot be targeted directly. Behavior should be confirmed against the documentation for the installed adapter version.

• Which model fits a paginated list that must keep earlier pages visible?
• Does a deferred prop survive a partial reload that does not name it?
• What changes between Inertia major versions?