Cursor Pager

For APIs that page by an opaque cursor (e.g. an AIP-158 pageToken) rather than a page index — there's no reliable page count to build a numbered pager against, and some cursor APIs cap how far next can go even when a requested total is higher. This pager only ever exposes prev/next, driven by the API's own "is there a previous/next page" signal — never a page index it invented itself.

Props

Server-driven tables

This pairs with DataTable's manualSorting + controlled sorting props for a fully server-driven table — each onPrevious/onNext (and each sort-header click) should trigger a real fetch or, in a Next.js Server Component page, a navigation to a new ?pageToken=… URL, not a re-slice of rows already sitting in memory. See the Server-driven tables note in the ui-kit Storybook (Foundations) for the full pattern, including the Next.js App Router shape and the skip-ceiling gotcha that motivated never deriving hasNext from a total count.

Do / Don't

• Do set hasNext/hasPrevious from the API's own paging signal (e.g. a non-empty nextPageToken), not from comparing rows-seen-so-far against total.
• Do omit total entirely when the caller didn't request it — don't estimate or reuse a stale count.
• Don't reach for this when the API pages by index — use Numbered Pager instead. Most RMS list endpoints accept a page parameter since RMS-1479, so cursor paging is now the exception rather than the default.