Add pagination with AI: stable ordering, filters and honest totals

A worked example: where the task becomes difficult

A fictional customer dashboard loads every order and slices the array in the browser. It becomes slow as history grows. The team wants server pagination, but ordering only by a timestamp with ties can repeat or skip records. Start with controlled orders sharing dates and a clear sort key. Decide whether customers need numbered pages or a next-cursor journey.

Decisions to make before implementation

Compare offset and cursor approaches against the task, not a universal preference. Define how filters and sort order participate in pagination identity. Reset the current page when a filter changes appropriately. Keep a deterministic secondary key for tied values. If exact totals are expensive, show an accurate alternative rather than generating a precise count from the current page length.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Specify ordering, filter semantics and the desired navigation model.
• Implement the receiving query with bounded page size and stable identity.
• Connect loading, empty, next-page and changed-filter states.
• Test tied values and inserts between requests using controlled records.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Implement bounded server pagination for this order list. Preserve supported filters and define a stable timestamp-plus-identity ordering. Choose cursor or offset based on the supplied navigation requirement. Validate page size and sort fields. Test tied dates and a changed filter; do not load the entire dataset just to simulate pagination.

Failure modes that an attractive preview can hide

Client-only filtering of one fetched page can hide matching records on other pages. Move the intended full-dataset filter into the query or label the limited scope clearly. Avoid fetch loops that retrieve every page to display a summary. Do not pass arbitrary sort-column names into a query without validating them against supported fields.

Technical references: MDN: form validation

Acceptance checks and the evidence to retain

Keep the query contract, navigation model and stability tests. Record whether totals are exact, estimated or intentionally not displayed.

Specific answers

Common questions