Choosing Between Offset‑Based and Cursor‑Based Pagination in RTK Query

Answer

For RTK Query’s useGetPostsQuery hook, choose cursor‑based pagination as the default when the dataset is large and experiences frequent inserts, deletions, or reordering.

Confirmed facts

• Offset‑based pagination uses limit and offset as part of the query key; RTK Query refetches whenever they change.
• If the underlying collection mutates between requests, the same offset can return duplicate or skipped items; RTK Query does not automatically correct this.
• Cursor‑based pagination returns an opaque token from the server; the token encodes a stable position (e.g., the last item’s ID) and yields consistent pages under mutations.
• RTK Query provides built‑in helpers like selectFromResult and skipToken that work naturally with offset‑based APIs; cursor‑based logic usually requires a custom transformResponse or manual query‑parameter handling.

Likely explanation / recommendation

When data changes often, offset‑based pages become unstable: inserting a record before the current offset shifts all later items forward, causing the next page to repeat the last item of the previous page; deleting a record creates a gap that skips an item. Cursor‑based pagination avoids this because the cursor points to a specific record, not a positional offset.

Therefore, for large, mutable datasets, cursor‑based pagination is the safer default. Offset‑based pagination remains acceptable only when:

1. The dataset is effectively static or changes infrequently.
2. UI only needs the first few pages (shallow paging) where the probability of mutation between requests is low.
3. Implementing cursor support on the backend would be prohibitively costly.

Mitigating duplicate/skipped items with offset‑based pagination

• Enforce a deterministic, unique sort order (e.g., ORDER BY id DESC, created_at DESC) so that inserts/deletes affect only one side of the boundary.
• Use RTK Query’s tagging invalidation: after a mutation that could affect the list, call api.util.invalidateTags(['Posts']) to force a refetch of the current page.
• Optionally, fetch a slightly larger page (limit + safetyMargin) and client‑side trim duplicates based on seen IDs.
• If you can add a “since” parameter (timestamp or ID) to the query, treat it as a lightweight cursor while still using offset for UI simplicity.

One missing diagnostic detail

Do you have a backend‑provided stable, unique field (e.g., auto‑increment ID or monotonic timestamp) that can serve as a cursor? If the answer is no, offset‑based pagination may be your only viable option, and you should apply the mitigation steps above.