Doesn't that strategy only work when you're paginating one page at a time, like Reddit?
How would you implement a deep pagination like "go to page 107" unless you can derive page 107 from your order criteria?
How would you implement a deep pagination like "go to page 107" unless you can derive page 107 from your order criteria?
Imagine a large forum topic. The user is just seeking through time. A deep pagination here is when the user knows what they're searching for is more than 1 page away.
The user would have to know a snippet of text or an explicit date range for your search box to help, so what about all the times they don't or if their filters are insufficient? This is why forums have both deep pagination and a search box.
It would be cruel to make the user paginate one page at a time just like it'd be unbearable if Youtube didn't let you jump 10 minutes at a time.
Obviously not every pagination needs deep pagination, but that's between you and your users, and it's what came to mind when I read that article.
What's the use case for that?
I’ve been thinking about it, and ideally one would make a search engine that only indexes pages that have no analytics, tracking, ads, paywalls, etc. Then I’d find those same pages I’m searching for.
To give an example: I found http://blog.deconinck.info/post/2016/12/19/A-Dirt-Cheap-F-Aw... on page 3 of Google for "raspberry pi led", just below https://tech.scargill.net/home-control-2016/ (both of which are interesting IMO)
Google is great for finding things you already know, but I'm using it for discovering things I didn't even know I was interested in.
I can't exactly just put the entire dictionary into google to try and find what I might like. I enter a category I might like, and look through the results matching that category.
You wouldn't. Keyset pagination forces the user to do the exact same thing people complain about you doing to the database. Want page 10 of results? Too bad, enjoy running through pages 1-9 and throwing them away. Except now everything is even slower because it's users talking to the service, not the service talking to the db.
There are plenty of use cases where that's a perfectly acceptable trade-off, or an annoying-but-necessary trade-off, but the people all up in a froth over the inefficiency of limit/offset seem to regularly fail to realize that they're advocating for a database performance solution with implications that reach all the way out to the UI/UX level.
At a minimum, I see very little in the way of acknowledgement of this factor.
For example, you could have a background process that slowly paginates through the table and saves off the page boundaries, which you can then use for jumping into. They will always be a bit off especially near the middle of the table, but that's probably okay.
There's lots of ways to do this fuzzy jumping that don't involve scanning the full table synchronously.
Second, you can just perform an indirection through offset (+ limit = 1).
That said, if users were doing this in my software I'd definitely be looking at how I can improve their workflow.