Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I dunno. I think we should jump between pages. I miss jumping to page 50 on search engine results just to see what was down there. Now you literally can't make it past page 10. Duck, Google and Bing just stop. There's nothing else.
You can have pagination and not having n+1 queries. We did it at my last company. Even when you search, you might need to go through pages 1-3 a lot of times. -
@whimsical but you can do that with keyset pagination.
I've done that for chat and it works just fine.
As the user scrolls up, make a request to seek older chats based on the previous last fetched key. No need for offset. -
-
In addition to my work as a frontend dev, I also have a master in cognitive psychology. I also worked for apple care and other call center, so I've been in the shoes of the actual user / worker.
There is absolutely a case where you want to jump to page 9824. For example if you need to go through all the data, which happen all the time. Being able to go through the data sequentially is essential. Search is of course essential too but you want your data paginated to give the user a sense of where he is at in the data. -
@whimsical how is this heavy??
> Gee, I wonder what it could be! Could it be that the DB is having to go through hundreds of rows just to return the 100001st row?
Just configure your indexes wtf -
@hjk101 both.
The backend implementation is often inefficient for large datasets.
The UI is also seldom practical. I mean, seriously, how often does a user want to jump from page 1 to page 2311?
Everywhere I worked, pagination was always limited to next/previous and instead we focused on making a very accurate search functionality. Users were happy as a result. -
This, 100%
I‘m so tired of having to explain to my team members why adding offset pagination is a bad idea in almost all cases.
As you said, there is no use case where a user wants to go to a specific page. The user just wants to go through all the items sequentially.
It‘s a nightmare when you also need to have client side filtering and/or sorting.
And let’s not forget that by the time that the user is on some page, one item could have been removed or added, fucking up the whole pagination.
The problem is that people just use it as the default go to solution for large lists of items.
Nothing is a silver bullet. Think of what you need first, then decide which design and implementation it should be.
*sigh* -
@null-pointer-ex I disagree with that. I've had the need for that quite a few times in the API. Mainly to resume work after a restart crash on processing a large result set. I do like record offset for this better than actual page offset. For previous/next or doom-scrolling (lazy loading) one also needs windowing in the API.
I've seen an edge case in UI too where the user shares a link with a specific page with another user but that is a very rare one. (Used to divide the work going through a list giving each worker a different starting point). But all edge cases I've seen can be solved by something better.
Oh sh*t
When the API is not documented.
Ladies and Gentlemen,
I present you the API I'm working with...
That's a pretty fucking useful error descrip...
Offset pagination is one of the biggest collective failures in software engineering.
Who wakes up one morning yearning to visit page 7218 of 100000 in the dataset? No one, right? Because that’s not how it’s supposed to work. That’s what the search feature is for. Not that developers don’t fuck it up too, but that’s the not the point of this rant.
The truth is, most developers are lazy and don’t want to properly handle stuff. It’s even made worse by ORMs, where some dumb ass will use Django to make a shitty API without a care in the world about the underlying database.
Then after a few months of ever increasing data, they start experiencing very slow queries and response times.
Gee, I wonder what it could be! Could it be that the DB is having to go through hundreds of rows just to return the 100001st row?
Designers also defaulting to Page 1 of 2322222 UI like the NPCs they are, is a big problem.
Pagination UI, if not done right, is a performance nightmare masquerading as a feature, solving a user problem that doesn't exist.
Fuck whoever came up with this bullshit.
I’ve had 3 side gigs where my task was to speed up the system and it always ended up being an issue with pagination. Once worked on a project where the dashboard toook 8 minutes. Yes, you read that right. 8 minutes to load. The company had accepted it as normal until a new manager joined and said, fuck that. Brough me onboard to unfuck the mess. No issue with Django devs, but bro, learn how to deal with databases properly for fuck's sake.
Before you came at me with, “well, what if I want to give users the ability to jump between pages”. Bro, that’s what search is for! If search is not allowing users to access the exact data they want, then it’s broken.
Pages are not deterministic anyway, because page 4 today won’t have the same data tomorrow.
I just fucking hate badly implementation pagination. Fucks up my day.
rant
pagination
database
api
orm