hasNextPage without computing total pages
Parent: Total count strategies for paginated UIs · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for hasNextPage without computing total pages. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- For Relay connections, endCursor corresponds to the last returned edge and can be non-null on a final nonempty page. Use hasNextPage for forward completion; when implementing lookahead, construct the continuation cursor from the last item actually returned, not the discarded extra item. (low confidence) [source]
- Do not infer completion from a short or empty response when consuming an API. AIP-158 permits fewer than the requested number, including zero, before collection end; Samsara documents omitted inactive objects and instructs clients to continue while hasNextPage is true. (medium confidence) [source]
Problems, failure modes and limitations
- In the bounded matching-result pattern, receiving exactly pageSize rows cannot distinguish a full final page from a page with further results. Looking for the additional row resolves that boundary without calculating the total; this follows from Relay's strict greater-than-first condition and Spring's pageSize + 1 retrieval. (medium confidence) [source]
- Lookahead removes the need for a count query but does not establish constant-time pagination. MongoDB can coalesce sort and limit to retain only the top N results; with an intervening skip it increases the sort limit by the skip amount. That optimization bounds retained results, not necessarily all work performed. (low confidence) [source]
- A continuation token is not universally proof that another matching record exists. Google requires a token when the service cannot determine exhaustion in time, and DynamoDB explicitly says a nonempty LastEvaluatedKey does not necessarily mean more result data. Distinguish permission to continue scanning from an exact matching-row existence test. (medium confidence) [source]
- Avoiding a total-count query does not remove deep-offset costs. Spring documents that offset-based Slice queries become inefficient at large offsets and separately describes indexed keyset windows that fetch limit + 1 results. (low confidence) [source]
- Relay requires consistent edge ordering across pages. It also scopes hasNextPage by direction: first/after requires an exact further-edge answer, while last/before permits false when the server cannot efficiently determine whether later edges exist. (low confidence) [source]
Comparisons and alternatives
- Use the cursor of the last returned edge as the next request's after value. With an extra-row probe, the implementation must keep endCursor on the last displayed row, rather than the discarded probe row, so that the probe remains eligible for the next page. (medium confidence) [source]
Facts and statements
- For forward pagination over an ordered stream of matching results, fetch pageSize + 1 results, return the first pageSize, and set hasNextPage to whether the extra result exists. This implements Relay's more-than-first test and Spring's documented Slice fetch size without needing a total-count query. (medium confidence) [source]
- Continuation metadata can support forward navigation without total pages: Relay requires edges and pageInfo but does not require a total count, while Google AIP-158 makes total_size optional and communicates completion through next_page_token. (medium confidence) [source]
- Cursor pagination and hasNextPage suit sequential loading, but a cursor alone does not provide arbitrary page-number jumps or an exact total. Mironsoft describes both limitations and recommends matching the navigation model to the UI. (low confidence) [source]
- Incorrect continuation metadata can silently truncate client output. In an August 2022 GitHub GraphQL regression, a repository query returned hasNextPage=false despite further results; the reporter's generated profile lost project listings. A GitHub reply dated September 2, 2022 said the bug had been fixed about a week earlier. This is historical evidence, not a claim of a current defect. (low confidence) [source]
- Total counts are optional for forward traversal: a response can expose a next-page boolean or continuation token independently of total rows and total pages. Relay specifies pageInfo without requiring totals, Google makes total_size optional, and Spring distinguishes Slice from Page. (high confidence) [source]
- A Next or Load more interface can use continuation metadata alone. A numbered last-page control needs additional information: Spring's Slice does not report total pages, while Google's pagination response permits omitting total_size. (medium confidence) [source]
- Do not infer completion from a short or empty API response. Google permits zero results before collection exhaustion, Samsara documents empty pages with hasNextPage true, and DynamoDB can filter out every evaluated item while returning LastEvaluatedKey. Follow the API's continuation contract. (high confidence) [source]
Children
- Lookahead pagination boundary testing (frontier)
- Cursor ordering and continuation contracts (frontier)
- Limit-plus-one lookahead (frontier)
- Continuation tokens versus matching-row existence (frontier)
- Cursor boundary correctness (frontier)
- Short and empty page handling (frontier)
Frontier under this node: Continuation tokens versus matching-row existence, Cursor boundary correctness, Cursor ordering and continuation contracts, Limit-plus-one lookahead, Lookahead pagination boundary testing, Short and empty page handling