How to Build a Cursor Pagination Load More Feed in React and Flask

Why "Load More" keeps repeating the first page

The React button already sends the cursor it got back from the last response:

const r = await fetch(`/api/items?cursor=${cursor ?? 0}&limit=10`);

So the bug is on the server. The endpoint reads the cursor query param but never uses it - it always slices from the top of the list:

@app.get("/api/items")
def items():
    cursor = int(request.args.get("cursor", 0))
    limit = int(request.args.get("limit", 10))
    # BUG: ignores `cursor` - always returns the first page.
    page = ITEMS[:limit]
    next_cursor = page[-1]["id"] if page else None
    return jsonify(items=page, next_cursor=next_cursor)

Every click re-fetches items 1..10, so the feed never advances.

Step 1 - page forward from the cursor on the server

Cursor pagination returns the next limit items whose id is strictly greater than the cursor. next_cursor is the id of the last item on the page, or null once the feed is exhausted so the client knows to stop:

@app.get("/api/items")
def items():
    cursor = int(request.args.get("cursor", 0))
    limit = int(request.args.get("limit", 10))
    page = [it for it in ITEMS if it["id"] > cursor][:limit]
    next_cursor = page[-1]["id"] if len(page) == limit else None
    return jsonify(items=page, next_cursor=next_cursor)

The key detail is next_cursor = page[-1]["id"] if len(page) == limit else None. A full page means there may be more, so return the last id. A short page means the feed is exhausted, so return null. A raw list here stands in for a real query - against a database the same logic becomes WHERE id > %s ORDER BY id LIMIT %s.

Restart Flask and page through it:

pkill -f "python3 app.py"; python3 app.py > /tmp/flask.log 2>&1 &
curl -s 'localhost:8000/api/items?limit=10'
curl -s 'localhost:8000/api/items?cursor=10&limit=10'

The first call returns ids 1..10 with next_cursor: 10; the second returns 11..20 with next_cursor: 20. No overlap, no gaps.

Step 2 - the React "Load More" button

The React side is already correct once the API pages forward. It appends each page to the list and stores the returned cursor; when next_cursor comes back null the button disables itself:

const [items, setItems] = useState<Item[]>([]);
const [cursor, setCursor] = useState<number | null>(0);

async function loadMore() {
  const r = await fetch(`/api/items?cursor=${cursor ?? 0}&limit=10`);
  const data = await r.json();
  setItems((prev) => [...prev, ...data.items]);
  setCursor(data.next_cursor);
}

<button onClick={loadMore} disabled={cursor === null}>
  {cursor === null ? 'No more' : 'Load More'}
</button>

Storing next_cursor (not a page number) in React state is what makes this stable: the client only ever asks for "the next items after id X".

Why cursors beat OFFSET for a feed

Offset pagination (OFFSET n) drifts when rows are inserted or deleted between requests - users see duplicates or skip items, and deep offsets get slow because the database still scans and discards the skipped rows. "Give me the next 10 after id X" is always correct and, with an index on the sort column, is a fast index seek at any depth. Real infinite-scroll feeds (X, Slack, the GitHub API) use an opaque encoded token over a stable sort key like (created_at, id) rather than a raw id, so the sort can be richer than one column - but the load-more contract is identical.