Solution

You'll build a small stateful client that pulls a paginated feed one page at a time — remembering the cursor between calls, piling up the items, and stopping the moment the server says there is nothing left.

The problem, in plain English

You're loading a comment thread with thousands of entries. The API refuses to hand you all of them at once — it gives you a page of, say, twenty, plus a cursor: a small token that means "the next batch starts here." To get the following page you send that token back. Get it wrong and you either re-fetch page one forever, or you throw away everything you already loaded. The fetcher's whole job is to keep that cursor straight and pile up the results as it goes.

The mental model

Think of a bookmark in a book. Each page ends with a bookmark tucked at the start of the next page, so you never count pages — you just follow the bookmark. The server's nextCursor is that bookmark. You start with no bookmark (null), and when a page comes back with no bookmark at all (nextCursor is null or undefined), you have reached the end.

A first attempt

A reasonable first try just fetches and returns whatever comes back:

function cursorPaginationFetcher(fetchPage) {
  let items = [];

  async function next() {
    const page = await fetchPage(null); // always asks for the first page
    items = page.items;                 // replaces the list instead of growing it
    return items;
  }

  return { next, items, hasMore: true };
}

Two things go wrong, both quietly. Every call passes the same null, so the server keeps returning page one — next() never advances. And items = page.items overwrites the accumulator, so even if the cursor did move you would be left holding only the most recent page, not the union. Nothing reads nextCursor, so hasMore is a frozen true that never learns the feed ended, and the items copied onto the returned object is the empty array captured at creation — it never reflects what you fetched.

The working solution

Keep three pieces of state in the closure — the accumulated items, the cursor for the next request, and a hasMore flag — and let next() update all three from each response.

function cursorPaginationFetcher(fetchPage) {
  let items = [];     // every item gathered so far, across all pages
  let cursor = null;  // where the NEXT page starts; null on the very first call
  let hasMore = true; // is there at least one more page to fetch?

  async function next() {
    if (!hasMore) return []; // exhausted: skip the network, resolve empty

    const page = await fetchPage(cursor);              // ask for the page at `cursor`
    items.push(...page.items);                         // append this page to the running list
    cursor = page.nextCursor;                          // the response tells us where to go next
    hasMore = cursor !== null && cursor !== undefined; // a nullish cursor means "the end"
    return page.items;                                 // resolve with just the page we fetched
  }

  async function all() {
    while (hasMore) {
      await next(); // pull one page at a time until there are none
    }
    return items; // hand back everything we accumulated
  }

  function reset() {
    items = [];
    cursor = null;
    hasMore = true;
  }

  return {
    next,
    all,
    reset,
    get items() { return items; },     // a getter: reads see the LIVE list, not a snapshot
    get hasMore() { return hasMore; },
  };
}

module.exports = { cursorPaginationFetcher };

The fix lives in next(). It reads the stored cursor and — the crucial line — writes the response's nextCursor back into it, so the following call resumes exactly where this one stopped. It appends instead of overwriting, and it derives hasMore from whether that new cursor is nullish. all() is then just a loop that runs next() until hasMore goes false. Exposing items and hasMore as getters — a getter re-runs its function on every read — is what keeps fetcher.items and fetcher.hasMore live instead of frozen at their empty starting values.

Walking through one call

Take the three-page feed from the prompt: fetchPage(null) returns { items: ['a','b'], nextCursor: 'c1' }, fetchPage('c1') returns { items: ['c','d'], nextCursor: 'c2' }, and fetchPage('c2') returns { items: ['e'], nextCursor: null }.

• First next() — hasMore is true, so we proceed. cursor is null, so fetchPage(null) returns ['a','b'] with nextCursor: 'c1'. We push 'a' and 'b' onto items (now ['a','b']), store cursor = 'c1', and keep hasMore = true ('c1' is not nullish). We resolve with ['a','b'] — just this page. fetcher.items now reads ['a','b'].
• Second next() — cursor is 'c1', so fetchPage('c1') returns ['c','d'] with nextCursor: 'c2'. items grows to ['a','b','c','d'], cursor becomes 'c2', hasMore stays true. Resolves with ['c','d'].
• Third next() — fetchPage('c2') returns ['e'] with nextCursor: null. items becomes ['a','b','c','d','e'], cursor becomes null, and hasMore flips to false because the cursor is now nullish. Resolves with ['e'].
• Fourth next() — hasMore is false, so we short-circuit: no fetchPage, resolve with [], and fetcher.items is untouched.

Calling all() instead of those four manual calls would have run the first three automatically and returned ['a','b','c','d','e'] in one shot.

Gotchas

• Not threading the cursor — calling fetchPage(null) (or fetchPage()) every time pins you to page one forever. Fix: store page.nextCursor after each fetch and pass it as the next call's argument.
• Replacing instead of appending — items = page.items discards earlier pages. Fix: append with items.push(...page.items) so items is the union of all pages.
• Testing the cursor with a falsy check — if (cursor) treats a legitimate cursor of 0 or '' as the end. Fix: check for nullish specifically (cursor != null, or !== null && !== undefined).
• Exposing items / hasMore as plain properties — a value copied onto the returned object at creation freezes at the empty start. Fix: use getters so every read returns the current variable.
• Forgetting the exhausted-next() guard — without if (!hasMore) return [], a next() after the end re-runs fetchPage(cursor) where cursor is now null, silently re-fetching page one. Fix: short-circuit to an empty array when hasMore is false.

Going further

• Guard overlapping calls — this version assumes you await each next() before the next. If two overlap, both read the same cursor and fetch the same page. Store the in-flight promise and hand it to callers until it settles.
• Resume after an error — because a rejected fetchPage throws before the state updates, the cursor is untouched and a retry resumes from the same spot. You could wrap the fetch in automatic retry-with-backoff on top of that.
• Surface loading state — track an isLoading flag or a pageCount so a UI can show a spinner or "page 3 of ?" while pages stream in.
• Cancellation — thread an AbortController into fetchPage so an in-progress page load can be cancelled when the user navigates away.