Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pagination with rel=“next” and rel=“prev” (2011)

webmasters.googleblog.com

Post reply on HN
Print view View original

51–60 of 96 posts

Re: Pagination with rel=“next” and rel=“prev” (2011)

#51

Post by jalfresi »

austinjp wrote: post #48
amelius wrote: post #17

Earlier quoted context omitted.

Can anybody point to an implementation of infinite scroll that actually works? I know facebook's implementation doesn't work correctly because the scrollbar breaks when scrolling down using it.

Seems that we can learn lessons from comments here, and hopefully some can point to a decent implementation, or build one. Salient points seem to be: # Update URL during scrolling so links don't break, and link to the "deep" item not just the first page. # Don't break history, so back/forward/reload buttons act as would be expected. # Truly endless scrolling kills browsers due to consuming increasing resources, so do…

I've seen implementations on other systems where this has been solved by placing a vertical bar to the right of the window. The height of this bar represents the total length of the document. Inside this vertical bar is a small bar which represents the current viewing window on the document. The user can "scroll" this small bar to move the current viewport over the large document.

I think I might start overriding the existing methods which users are used to with this method because I've build websites for a couple of years and think I know better than years of UI development by much more experienced people than I.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#52

Post by deathanatos »

kevindeasis wrote: post #19

How do you guys implement / What's the best practice for paginating your db using sql and nosql? I know there are a bunch of gotcha's to look out for

http://use-the-index-luke.com/blog/2013-07/pagination-done-t...

Essentially, once your rows are ordered, your next page is "rows > the last row on the previous page, limit "

This has the fantastic benefit of being index-friendly, which OFFSET is not, and if you structure the URLs for the pages well, obvious what you're getting back. (e.g., if your records are by date, you might get /daily-reports?since=2015-01-04&limit=50 for the page that starts at 2015-01-04)

It's from an SQL site, but the concept is not specific to SQL. I'm working on an implementation of it for data stored in Mongo, at the moment.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#53

Post by danneu »

fbonetti wrote: post #35
kevindeasis wrote: post #19

How do you guys implement / What's the best practice for paginating your db using sql and nosql? I know there are a bunch of gotcha's to look out for

It's really easy to paginate data with SQL - just use LIMIT and OFFSET. limit = page_size offset = (current_page - 1) * limit For example, let's say you have a table with 1000 products in it, and you want to display page 3 with a page size of 50. Here's how you would write it: SELECT * FROM products LIMIT 50 OFFSET 100

The downside is that OFFSET is slow if you have a lot of items, like on a forum.

At which point you could assign each post in a topic an indexed `position` column that always increases from 0 within that topic, which lets you jump to arbitrary pages and parameterize perPage.

    fromPos = (page - 1) * perPage
    
    SELECT *
    FROM posts
    WHERE topic_id = $1
      AND position >= fromPos
      AND position
For simpler needs, your "Next" button could load items that come after the last ID on the current page but with a LIMIT.

    
      {% for item in items %}
        {{ item }}
      {% endfor %}
    

    Next

    SELECT *
    FROM items
    WHERE id > $afterId
    LIMIT $perPage
That's fast and really easy.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#54

Post by austinjp »

jalfresi wrote: post #51
austinjp wrote: post #48

Earlier quoted context omitted.

Seems that we can learn lessons from comments here, and hopefully some can point to a decent implementation, or build one. Salient points seem to be: # Update URL during scrolling so links don't break, and link to the "deep" item not just the first page. # Don't break history, so back/forward/reload buttons act as would be expected. # Truly endless scrolling kills browsers due to consuming increasing resources, so do…

I've seen implementations on other systems where this has been solved by placing a vertical bar to the right of the window. The height of this bar represents the total length of the document. Inside this vertical bar is a small bar which represents the current viewing window on the document. The user can "scroll" this small bar to move the current viewport over the large document. I think I might start overriding the…

Sounds familiar. I recall instances where the small vertical bar-within-a-bar you mention becomes vanishingly small, and the overall page size unmanageable, making "scrolling" a joke.

It would be nice to know if we're making progress on problems like this. Paging and scrolling both evolved to solve problems. Perhaps they're imperfect, or could stand improvement. Perhaps not. Regardless, an open-minded discussion would probably shed some light on current thinking.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#55

Post by tyingq »

detaro wrote: post #22

I wonder why they recommend putting tags into the head, instead of marking up existing tags (which you'll have in most cases for prev/next) with rel-attributes. Actual difference in parsing? Just because tags might not be on every site?

I believe it's to unambiguously tie the "next" to the page. Where the page content might have, for example, an that moves images around in a carousel.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#57

Post by lox »

danneu wrote: post #53
fbonetti wrote: post #35

Earlier quoted context omitted.

It's really easy to paginate data with SQL - just use LIMIT and OFFSET. limit = page_size offset = (current_page - 1) * limit For example, let's say you have a table with 1000 products in it, and you want to display page 3 with a page size of 50. Here's how you would write it: SELECT * FROM products LIMIT 50 OFFSET 100

The downside is that OFFSET is slow if you have a lot of items, like on a forum. At which point you could assign each post in a topic an indexed `position` column that always increases from 0 within that topic, which lets you jump to arbitrary pages and parameterize perPage. fromPos = (page - 1) * perPage SELECT * FROM posts WHERE topic_id = $1 AND position >= fromPos AND position For simpler needs, your "Next" butto…

This sounds like a really premature optimization to me. Let the DB do it's job unless you have an explain trace showing it's slow for your workload. Trying to do things like sequence columns adds complexity, when this is often handled by the engine.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#58

Post by lucasmullens »

lox wrote: post #57
danneu wrote: post #53

Earlier quoted context omitted.

The downside is that OFFSET is slow if you have a lot of items, like on a forum. At which point you could assign each post in a topic an indexed `position` column that always increases from 0 within that topic, which lets you jump to arbitrary pages and parameterize perPage. fromPos = (page - 1) * perPage SELECT * FROM posts WHERE topic_id = $1 AND position >= fromPos AND position For simpler needs, your "Next" butto…

This sounds like a really premature optimization to me. Let the DB do it's job unless you have an explain trace showing it's slow for your workload. Trying to do things like sequence columns adds complexity, when this is often handled by the engine.

You need this if it's for a feed that gets frequent updates. Imagine a paginated Twitter feed, and the user clicks a link with ?page=3, and suddenly there's a new tweet, causing page 3 to have a tweet the user saw on page 2. Using afterId solves that.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#59

Post by objclxt »

pmarreck wrote: post #39
fbonetti wrote: post #35

Earlier quoted context omitted.

It's really easy to paginate data with SQL - just use LIMIT and OFFSET. limit = page_size offset = (current_page - 1) * limit For example, let's say you have a table with 1000 products in it, and you want to display page 3 with a page size of 50. Here's how you would write it: SELECT * FROM products LIMIT 50 OFFSET 100

And if the data frequently changes during pagination?

That's why it's often better to use a cursor in your client-facing API (or a pseudo-cursor that maps to something you have in your database), rather than passing the limit/offset through.

Re: Pagination with rel=“next” and rel=“prev” (2011)

#60

Post by ibejoeb »

detaro wrote: post #22

I wonder why they recommend putting tags into the head, instead of marking up existing tags (which you'll have in most cases for prev/next) with rel-attributes. Actual difference in parsing? Just because tags might not be on every site?

There is only one next in the sequence, but there may be multiple navigational elements that bring the user there. For example, links in both a header and a footer.
Post reply on HN