Hacker News Reader

Comment by mewpmewp2 | Hacker News Reader

I think that cursor should be used more with realtime data and more stable data like products in an e-commerce shop should use paginated queries.

There's many UX benefits for paginated queries. It gives customer a clear overview of how many products there are and customer can also navigate faster to get a better understanding of what general prices are. If the table/list doesn't have good filters, customer can easily act out binary search to find what they are looking for in an ordered list of items.

Same with highscores, forums threads and other similar things. Say you are browsing highscores and you want to see what scores are around 10000th position etc.

As a user I find having only prev/next buttons a bit claustrophobic in this case. I think UX should trump whatever performance gains there are from it.

View on HN

A while ago, github replaced the pagination on their commits page to be based on a git commit ID instead of a page number. After that change, it made it a lot more difficult to find the oldest commit in a large repo - frustrating.

That said, I think the percent of average ability internet users (ie. people visiting an ecommerce shop) will virtually never attempt to navigate by changing values in a query string param. High scores on a gaming forum, maybe more likely. Either way, if users need the ability to jump through pages, I would hope that would be exposed in a UI rather than expecting people to edit the URL directly.

Yeah, it's best if it's possible to do it both ways. With url and also by clicking links and maybe even add a select/input to go to certain page.

If you look at any e-commerce systems, ranging from WooCommerce to Shopify, Amazon and Walmart, I think they all use pagination. Some Amazon pages do have infinite scroll however

I have also been frustrated without having the ability to quickly go through commits... Or I think releases for that matter?

For instance, browsing through tags/release versions, which should be a very valid use-case in my opinion also uses cursor based navigation.

The move from page-based pagination to cursor based pagination on the commits page was so that the underlying queries could be moved to GraphQL, which use cursors (specifically the GraphQL Relay specification). That was one of the first pages that was moved over, and these days I think it would be relatively trivial to add a “last” page, since the Relay connection has the concept of totalCount and we have a few tricks around first/last cursors. Theoretically the ordering could also be flipped to view the first commit on the first page.

Interesting, but right now it seems they return HTML and use some sort of Turbolinks like logic to make it seem single page app? Or is GraphQL not yet implemented there / used on some other layer in backend for example?

Oh sorry, I should have clarified it’s GraphQL “under the hood” (backend). Most of GitHub is a Rails app, and in the case of the commits page, the controller makes a GraphQL query, and then takes the results and injects it into the view, all server side. The original idea was that if GitHub was using its own GraphQL API to build its pages, our users would have the exact same access as GitHub engineers.

> A while ago, github replaced the pagination on their commits page to be based on a git commit ID instead of a page number. After that change, it made it a lot more difficult to find the oldest commit in a large repo

git log has a reverse option to reverse the order of commits displayed. You can also provide a commit reference like HEAD~10 to get the 10th ancestor from the head commit.

Does Github have a way to specify URL parameters to achieve something similar?

Not on that page, no, but you could easily fetch this information via the GraphQL API.

Reply on news.ycombinator.com