Inertia.js Infinite Scroll: Why Page 2 Replaced Existing Posts Instead of Appending Them

Alyona Yakymiv — Fri, 11 Sep 2026 10:16:07 +0000

Infinite Scroll in ICanUp initially looked correct. The first page of Posts loaded, I scrolled down, the request for page=2 completed, and the server returned the next records.

Then something unexpected happened: the Posts from page 1 disappeared, and only the records from page 2 remained.

The interesting part was that pagination itself worked. The data arrived. The problem was how the next page became part of the list that was already on screen.

For Infinite Scroll, successfully loading page 2 is not enough. The application needs an explicit rule for when a response replaces the list and when it extends it.

What I Saw on the Page

Before scrolling, everything looked normal: the list contained records from the first page.

After the next page loaded, the server returned new Posts, but the previous list was no longer preserved.

The problem was not that page 2 failed to load.

The problem was that page 2 became the new complete list.

Step	Actual	Expected
Initial load	`page=1`	`page=1`
First scroll	`page=2` replaces `page=1`	`page=2` appends after `page=1`
Next scroll	Only the latest page remains	All loaded pages remain

Infinite Scroll Changes the Meaning of Pagination

For traditional pagination, replacing the list is completely normal. A user opens page 2 and sees the records from page 2.

Infinite Scroll has a different contract.

The next page is a continuation of data that is already visible.

That difference determines whether the local list should be replaced or extended.

Two Different Pagination Contracts

Traditional pagination:

page=1 -> [1, 2, 3, 4]
page=2 -> [5, 6, 7, 8]


Infinite Scroll:

page=1 -> [1, 2, 3, 4]

page=2 ->
[1, 2, 3, 4, 5, 6, 7, 8]

page=3 ->
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]

Replace and Append Are Different Operations

A simplified version of the bug can be represented as assigning every new response to the same list.

That is correct for the first page.

For page 2 and later pages, it destroys the accumulated result.

Simplified List Replacement

posts.value = response.data;

Infinite Scroll needs different semantics: the first page creates the initial state, while later pages extend it.

The page number affects not only the request URL but also how the local state should be updated.

Replace for Page 1, Append for Later Pages

posts.value = page === 1
    ? response.data
    : [
        ...posts.value,
        ...response.data,
    ];

These snippets demonstrate the state contract rather than reproducing a specific production class.

Page 1 creates the list, while page > 1 extends it.

Page 1 Really Is Different

It may seem simpler to always append, but that creates another bug.

When the user opens another category, changes a filter, or switches locale, the existing results no longer belong to the new context.

An initial load is allowed to replace the list.

A continuation of the same result set is not.

Pagination State Is Part of the List

An array of Posts is not enough.

Infinite Scroll also needs to know:

which page has already been loaded;
whether another page exists.

Pagination metadata is as important as the records themselves. Without it, the frontend can request the same page repeatedly or continue after the final page.

Simplified Pagination State

const pagination = {
    currentPage: response.current_page,
    lastPage: response.last_page,
};

const hasMore =
    pagination.currentPage < pagination.lastPage;

The exact metadata shape depends on the application response, but the rule is the same.

The decision to load again should come from pagination state, not simply from another scroll event.

Append Introduces a Second Problem: Duplicates

Once the list starts accumulating pages, repeated requests need to be considered.

The same page can potentially be requested more than once because of UI state or closely timed load events.

Simply concatenating arrays can then render the same Post twice.

One Way to Prevent Duplicate Post IDs

const merged = [
    ...posts.value,
    ...response.data,
];

posts.value = [
    ...new Map(
        merged.map(post => [
            post.id,
            post,
        ]),
    ).values(),
];

Map is only one possible implementation.

The important invariant is that receiving the same Post again must not create another card.

Concurrent Loads Need a Guard Too

Infinite Scroll reacts automatically to page state, so another load should not start while the previous one is still running.

There is also no reason to send another request after the final page has been reached.

Guard Against an Unnecessary Next Request

if (
    loading.value
    || ! hasMore.value
) {
    return;
}

This prevents overlapping requests and avoids requesting pages after the result set has already ended.

A Context Change Must Reset the List

This was the other important behavior that needed to remain correct.

Category, filter, and locale define which Post result set the user is currently viewing.

If any of them changes, the accumulated list can no longer be continued.

A new context means:

a new page 1 and a new initial list.

Simplified Context Reset

const contextKey = [
    locale,
    category,
    filter,
].join(':');

if (
    contextKey !== currentContextKey.value
) {
    posts.value = [];
    currentPage.value = 1;
    currentContextKey.value = contextKey;
}

The resulting behavior becomes explicit:

Event	List operation
`page=1`	Replace
`page=2`, `page=3`, ...	Append
Category changes	Reset and load `page=1`
Filter changes	Reset and load `page=1`
Locale changes	Reset and load `page=1`

Inertia.js Was Not the Real Problem

It is easy to initially blame the framework because the problem appears when new page data arrives.

In this case, the more important boundary was between server pagination and local list state.

Inertia.js can deliver the new data, but the application still needs to know whether that data represents:

a new page state; or
a continuation of an accumulated result set.

This was not the first Inertia.js problem that made me look more carefully at the server-client boundary. I previously wrote about a case where meta tags existed in the browser but were missing from the initial HTML.

The framework can transport the data correctly while the application still applies the wrong state transition.

I Prefer an Explicit Update Mode

After this case, I prefer a model where the list update mode is visible from the context.

The first page or a new filter means reset.

The next page of the same result set means append.

When that distinction is explicit, the behavior becomes easier to read, test, and change.

Explicit List Update Mode

function applyPage(
    items,
    {
        reset = false,
    } = {},
) {
    posts.value = reset
        ? items
        : mergeUnique(
            posts.value,
            items,
        );
}

The implementation may differ, but the intent is now visible at the call site.

That makes the state transition much harder to misunderstand.

What I Verify After the Fix

After changing the list update behavior, I verify the entire sequence rather than only checking whether the next request succeeds:

The first page creates the initial Post list.
After page 2 loads, Posts from page 1 remain visible.
Page 3 and later pages append in the same way.
Post ordering remains stable after several loads.
Loading the same page again does not create duplicates.
No additional request starts after the final page.
Changing category resets the previous result set.
Changing a filter resets the previous result set.
Changing locale does not mix Posts from different locale contexts.

The Most Valuable Tests Cover a Sequence of States

A unit test for one array-merging function does not prove that Infinite Scroll works as a complete scenario.

The more useful checks cover a sequence:

page 1;
then page 2;
then another page;
plus separate context changes.

Scenarios That Should Remain Stable

Scenario 1:

page=1
-> [1, 2, 3]

page=2
-> [1, 2, 3, 4, 5, 6]


Scenario 2:

page=1
page=2
change category

-> old list cleared
-> new page=1


Scenario 3:

load page=2 twice

-> no duplicated Post IDs

After the fix, success means more than completing the next request.

The complete list, its ordering, and its current context all need to remain correct.

What I Would Avoid

Do not treat a successful page 2 response as proof that Infinite Scroll works.
Do not use the same array replacement for the first and later pages.
Do not append pages without duplicate protection.
Do not continue an old list after category, filter, or locale changes.
Do not determine whether another page exists only from a scroll event.
Do not hide the symptom with extra requests before defining the state update rules.

Infinite Scroll is not simply pagination without a button.

It changes the list update contract: the next page needs to continue the previous one.

What I Kept for Next Time

Define different update modes for page 1 and later pages.
Keep pagination metadata together with list state.
Prevent concurrent next-page requests.
Protect accumulated results from duplicate records.
Treat category, filter, and locale as part of the result-set context.
Start from a new page 1 when that context changes.
Test sequences of several pages instead of only a single request.

Conclusion

In this case, the server returned the correct next page.

The bug appeared when that data was applied to the existing list state.

Replacing page 1 with page 2 is normal for traditional pagination. For Infinite Scroll, it breaks the core behavior.

In ICanUp, the contract became simple:

the first page creates the list;
later pages extend it;
repeated Posts do not create duplicates;
changing category, filter, or locale starts a new result set.

The distinction between reset and append turned out to matter more than the mechanism that actually loaded page 2.

DEV Community: Alyona Yakymiv