If loading page 2 replaces the posts from page 1, Inertia is probably receiving the paginated posts as a normal prop instead of a prop configured for infinite-scroll merging. Inertia v2 documents Inertia::scroll() as the Laravel-side helper for configuring that behavior and pagination metadata. On the client, <InfiniteScroll> must point to the same prop your page renders. The exact API depends on your installed Inertia version and server adapter.
Why page 2 replaces the existing posts
A regular page prop can be updated with the new response value, replacing the old value. Infinite scrolling needs the paginated prop to be configured for merging so records from subsequent pages can be combined with the existing list. Inertia v2’s infinite-scroll documentation describes the server-side Inertia::scroll() helper for this purpose and for normalizing pagination metadata. Inertia v2: Infinite Scroll
As an Amazon Associate I earn from qualifying purchases.
Two settings that sound related do not perform that merge. preserveState retains local page-component state, while preserveScroll retains the viewport position. Neither one concatenates paginated records. Inertia v2: Manual Visits Inertia: Scroll Management
Check your Inertia version and server adapter
Start by identifying the installed client and server-adapter versions. The Inertia v2 infinite-scroll page notes that v3 is now the default, so its Laravel example should not be copied blindly into a project using another major version or adapter. Use the documentation for the versions actually installed. Inertia v2: Infinite Scroll Inertia v1 Upgrade Guide
#1 Best Overall
For Laravel projects following the documented v2 example, the paginated prop is returned through the scroll helper:
'posts' => Inertia::scroll(Post::paginate(...))That helper configures the prop for scrolling and provides pagination information. Other adapters, versions, or custom paginator payloads may require a different API; check their matching documentation rather than assuming this Laravel syntax applies everywhere.
Verify the server prop and client binding match
Configure the server-side prop
Confirm that the response marks the paginated posts prop for scroll merging, rather than returning it as an ordinary prop. If you build a custom pagination payload instead of using a supported paginator, provide the page and navigation metadata through the metadata mechanism supported by your adapter. Without usable pagination information, the client may not know which page to request next. Inertia v2: Infinite Scroll
Point InfiniteScroll at that exact prop
The client component’s data value must name the same prop key the server returns. In the v2 example, <InfiniteScroll data="users"> is paired with content rendered from users.data. For posts, use the corresponding posts prop and render the records from its actual payload shape. A mismatch between the component binding and the rendered prop can prevent the intended scrolling behavior.
Rank #3
Trace one request from page 1 to page 2
- Inspect the initial response. Check that the posts prop has the expected paginated data shape and includes usable pagination metadata.
- Check the merge configuration. Verify that the server adapter and installed version mark posts as a scroll/merge prop, using the version-appropriate helper or API.
- Check the client binding. Confirm that
<InfiniteScroll data="posts">matches the response prop name and that the list renders the records inside that prop. - Check the next-page request. Confirm that the request uses the expected page parameter and that the response represents the next page, not a replacement query or a reset.
- Compare versions if the wiring looks correct. Make sure the client and server adapter APIs are compatible, then consult documentation for those installed versions.
Inertia’s component uses intersection observers to detect when a user nears the end of the content and request another page. If the request happens but the existing records still disappear, focus on the response prop’s merge configuration and metadata rather than scroll-position settings. Inertia v2: Infinite Scroll
Reset the list when filters change
Appending is appropriate while the user continues through the same result set. After a filter change, however, the old posts may no longer belong with the new results. Reset the scroll data when starting that new result set so the filtered response replaces the prior collection rather than merging into it. Inertia v2: Infinite Scroll
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Keep partial reloads separate from infinite-scroll merging
Partial reloads can update selected props while retaining other client-side props, but that general behavior is distinct from configuring a paginated prop for infinite-scroll merging. If a partial reload is involved, check which props the request returns and how they are updated; do not treat partial reloads, preserved component state, or preserved scroll position as substitutes for the scroll prop configuration. Inertia v2: Partial Reloads Inertia v2: Manual Visits
What to conclude if the problem persists
A GitHub issue titled “Infinite Scrolling and merge props not working as expected” records a reported problem, but it does not establish one universal cause. Inertia issue #2120 If your response metadata, prop name, page parameter, and merge configuration all check out, compare the installed client and server-adapter versions and use their matching documentation to investigate the remaining mismatch.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
