Why cursors beat offsets when data changes
Page 1 is posts 8, 7, 6 for both. A new post makes the offset API return 6 again (a duplicate). A deleted post makes it skip 5 (the user never sees it). The cursor API returns 5, 4, 3 both times.
Long collections arrive in pages: numbered pagination, a Load more button, or infinite scroll that fetches the next page when an invisible sentinel element comes into view; doing it right means cursors instead of offsets, one request at a time, de-duplication, an end state, retry on errors and bringing users back to the same place.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write appendUnique(oldItems, newItems) that appends without duplicate ids and keeps the old order.
Change the first example to a Load more button instead of a sentinel (keep the guard, end and retry).
Explain it without notes
Compare offset and cursor pagination. When would you choose each?
How do you implement infinite scroll without listening to scroll events?
List the bugs a naive infinite scroll has and how to prevent each.
When should a product use numbered pagination instead of infinite scroll?
Preview
Console
Nothing logged yet.Expected console output
New post 9 added | offset page 2: 6,5,4 | cursor page 2: 5,4,3
Post 7 deleted | offset page 2: 4,3,2 | cursor page 2: 5,4,3