this post was submitted on 19 Aug 2024
74 points (96.2% liked)
Programming
17020 readers
238 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
In time-based pagination, the suggested fix to lots of data in a selected timespan is:
This means clients can't see all the results, unless you add a way to view other pages of data, which is just pagination again. Or is the intended design that clients view either the first x results (the default) or view all results?
The problem with articles like OPs and others is that they don't allow custom sorting, which is often a requirement, e.g. interfaces that present the data in a table, where column headers can be clicked to sort.
Regarding your first paragraph, this results limit is per page. To get the next page, you take your timestamp of the last item and use it in
from_time, or whatever you've called it. It's still a pagination technique.Regarding custom sorting, some of the techniques in the article can do this, some of them can't. Obviously timestamp based pagination can't, however the ID-based pagination that I mentioned can.