The task and original case
Build a pagination client that collects unique records and stops for the right reason. Use the supplied page fixtures rather than a live API. The finished work should distinguish an overlapping record from a repeated cursor, because one is normalizable data and the other can trap the client in a loop.
| Case element | Value or requirement |
|---|---|
| Inputs | Page 1 IDs[1,2]; page 2 IDs[2,3]; a final page has no next cursor. |
| Build | A small pagination client, fixture pages and a termination test. |
This is an original invented exercise. It is independent practice, with no employer assessment or open-vacancy claim. Download the inputs, attempt your own result, then open the separate answer key.
Data and worked inputs
Build a result another person can follow
Create a function that accepts a page-fetching function so tests can supply local responses. Maintain a map keyed by record ID, the next cursor, a set of visited cursors and a declared maximum page count. The supplied page fixtures use an ids array. Map those IDs to items such as {id:1} in your test adapter, or let the client consume ids directly. Read each response, check its HTTP status, validate that declared array, record overlapping IDs and update the map under a documented conflict policy.
MDN explains that Fetch responses require explicit HTTP-status checks. For this exercise, request page one, then follow its next cursor. Stop when next is absent. Before requesting a cursor, reject one already visited; also stop with a clear error at the page bound. A successful termination and an incomplete error termination must have different result states. Do not label a partial collection complete after a failed request.
Sources[1]
Check the worked result
Page one contains IDs 1 and 2. Page two contains IDs 2 and 3 and has no next cursor. You read four row appearances, retain three unique records and record one overlap. The final successful state contains IDs 1, 2 and 3 and a normal end-of-pagination reason.
Keep enough of the request log to show both cursors and response counts. The unique-record map prevents ID 2 from being duplicated, but it cannot by itself prevent repeated requests. That is why cursor state has a separate guard.
Make the failure visible
Make page two return page one's cursor. The client should stop with a repeated-cursor error rather than repeatedly fetching the same page. Then change ID 2's payload on page two. Either accept a declared newest-value rule or report the conflict; do not silently assume duplicates are identical. Test a malformed items field and an HTTP failure independently.
Revise it and ask someone to reproduce it
Have a peer append a third valid page and predict its unique count. Keep the old two-page fixture as a regression check. In the next revision, reduce the page bound so the new fixture stops incomplete, and verify that your UI or report never presents its partial count as a complete export.
- Normal completion returns three unique records and one overlap.
- Cursor repetition and page bounds terminate with inspectable errors.
- HTTP or schema failures cannot produce a misleading complete state.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Built a fixture-driven pagination client with identity-based deduplication, repeated-cursor detection and explicit incomplete-result states.”
Use Projects or Independent practice as the heading. Keep the input files, result and revision together. Describe only your own completed work; the invented numbers are model outputs, not employer results or measured business impact.