5 ms·

how do you jump to arbitrary pages with cursor pagination?

tshaddox 4y ago
You generally don’t, unless you want to linearly scan through n pages. If your API is using offset or page numbers and the underlying collection is also having items added or removed, the behavior is undefined or straight up wrong. I think it’s okay to use offsets or page numbers in cases where the collection is static or where it’s acceptable to occasionally skip over an item or see a duplicate item while paginating.
- Aeolun 4y ago
  Or where you want people to be able to send each other links of the ‘look on page 11’ kind.
  - scottbruin 4y ago
    Going with the point re: cursor links, if your URLs look something like this then they would be shareable and more stable than page=11. ?startWith=<item_id>&sortBy=<alpha|datetimedesc|whatever>
    - Aeolun 4y ago
      Just impossible to navigate to by voice. In the office here people often call out the number of the page, but nobody will call out cursor AHgeuusn5d
singron 4y ago
You don't, but if your cursor is just a position in some well-defined order, you can sometimes craft a cursor out of a known position. Continuing the book metaphor, instead of skipping to page 100, which has no semantic meaning, you could skip to the beginning of the "M" section of the dictionary, or see the first 10 words after "merchant".
- joshspankit 4y ago
  Forum posts are the classic pagination example (in my mind), but I feel like the type of cursor pagination you’re talking about might work better. Skipping forward by date, by username, or even by concept might make long threads much quicker to scan through and understand.
lazide 4y ago
Depending on what you mean by ‘page’, you probably want a query? (Show me all results with values between 1 and 10) If you want to jump ahead in the results, that is fundamentally unstable though.
donw 4y ago
I see three options if this is a necessary use-case against a shared-changeable dataset: 1. Accept that the results will be unstable as the underlaying set changes. Pagination may either miss or double-include items unpredictably. 2. Store an intermediate result set guaranteed to remain stable for the necessary duration. This will provide stable pagination, at the cost of solving cache-expiry problems. 3. Use or build a version-controlled data store. I don't know of anything in common use, but there is likely something available. This is similar to #2, but moves the work from the application into the data-storage layer. You then paginate against a set version of the data. Imagine something similar to Immutable, but with expiry for unreachable nodes. Unsure what #3 looks like at scale.

You generally don’t, unless you want to linearly scan through n pages. If your API is using offset or page numbers and the underlying collection is also having items added or removed, the behavior is undefined or straight up wrong. I think it’s okay to use offsets or page numbers in cases where the collection is static or where it’s acceptable to occasionally skip over an item or see a duplicate item while paginating.

Aeolun 4y ago
Or where you want people to be able to send each other links of the ‘look on page 11’ kind.
- scottbruin 4y ago
  Going with the point re: cursor links, if your URLs look something like this then they would be shareable and more stable than page=11. ?startWith=<item_id>&sortBy=<alpha|datetimedesc|whatever>
  - Aeolun 4y ago
    Just impossible to navigate to by voice. In the office here people often call out the number of the page, but nobody will call out cursor AHgeuusn5d

singron 4y ago

You don't, but if your cursor is just a position in some well-defined order, you can sometimes craft a cursor out of a known position. Continuing the book metaphor, instead of skipping to page 100, which has no semantic meaning, you could skip to the beginning of the "M" section of the dictionary, or see the first 10 words after "merchant".

joshspankit 4y ago
Forum posts are the classic pagination example (in my mind), but I feel like the type of cursor pagination you’re talking about might work better. Skipping forward by date, by username, or even by concept might make long threads much quicker to scan through and understand.

lazide 4y ago

Depending on what you mean by ‘page’, you probably want a query? (Show me all results with values between 1 and 10) If you want to jump ahead in the results, that is fundamentally unstable though.

donw 4y ago

I see three options if this is a necessary use-case against a shared-changeable dataset: 1. Accept that the results will be unstable as the underlaying set changes. Pagination may either miss or double-include items unpredictably. 2. Store an intermediate result set guaranteed to remain stable for the necessary duration. This will provide stable pagination, at the cost of solving cache-expiry problems. 3. Use or build a version-controlled data store. I don't know of anything in common use, but there is likely something available. This is similar to #2, but moves the work from the application into the data-storage layer. You then paginate against a set version of the data. Imagine something similar to Immutable, but with expiry for unreachable nodes. Unsure what #3 looks like at scale.