When the list is too long for one screen, how do I page through it?
Offset and cursor pagination solve different problems. Pick a page size and keep the old page on screen so the layout does not jump.
Offset or cursor, not both by accident
Offset pagination jumps to any page by number, which is easy for a stable admin table. Cursor pagination points at the next batch and stays correct even when records get inserted or deleted mid-scroll. Check which one your API supports before you commit to either.
My list is [describe it and how often records change]. Should I use offset/page-based or cursor-based pagination, and what must my API expose for the option you pick?
Keep the old page while the next one loads
If the list collapses to a spinner on every next click, the height jumps and you lose your scroll position. Keep the previous page on screen until the new data lands, and show a quiet loading hint instead of a blank screen.
Moving between pages of [describe my list] makes the layout jump because the list empties while loading. How do I keep the previous page on screen until the next arrives, and what page size fits [describe the row content]?
Match the pagination style to how your data changes: offset for stable tables, cursor for live feeds. Then keep the previous page on screen so the layout never jumps.
Additional Resources
Explore these carefully curated resources to deepen your understanding and practice the concepts covered in this lesson.

