[Twey]

The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added. To get truly bookmarkable list URLs, the best approach I've seen is ‘page starting from item X’, where X is an effectively-unique ID for the item (e.g. a primary key, or a timestamp to avoid exposing IDs).

[bubblyworld]

Yeah, solving this edge case properly can add a lot of complexity (your solution has the same problem, no? deletes would mess it up as would updates, technically). I've seen people using long-lived "idempotency tokens" point to an event log for this but it's a bit nuts. Definitely worth considering not solving it, which might be a more intuitive UX anyway (e.g. for leaderboards).

[yxhuvud]

It doesn't have the problem if a timestamp or similar is used.

[ehutch79]

Only if you order by that timestamp.

[wackget]

Dunno why you've been voted down; you're totally right. The method you mention is called token/cursor/keyset-based pagination.

[nebezb]

He’s being downvoted because suggesting cursor pagination in an example describing sorting by price (descending) is plainly wrong. While neither is bookmarkable, cursor pagination is much worse. The UX went from “show me _almost_ the most expensive items” to “show me everything less expensive than the last item on the page I was on previously — which may be stocked out, more expensive, or heavily discounted today”. The latter isn’t something you’d bookmark.

[Twey]

If you believe that the user wants to see everything around a particular price point, e.g. because they've ordered their search results by price, then the correct cursor token is the price point of the top item (or the price point of the last item on the previous page, as an open bound, or even something fancier like the median price of the items in the page).

There's a choice to be made about semantics, and you have plenty of information given to you by the user in a search scenario, but ‘page 2’ is not the right choice because it has no useful semantics. If the user is hoping to bookmark the page it's because they want to preserve some property of the data for later, even in the face of data changes. I can almost guarantee that property isn't ‘items that happen to be on page 2 today’.

[the_arun]

I cannot think of any other way to bookmark anything static unless I convert it into pdf/screenshot before sharing. Are there better ways to bookmark a list page which guarantees same list forever?

[scarmig]

This depends on use case and who or what is actually consuming the pages. Most of the time, humans don't actually want the same list for all time (though what follows would work for them).

The only way to have a static list is to have an identifier for the state of the list at a certain time, or a field that allows you to reconstruct the list (e.g. a timestamp). This also means you need to store your items' data so the list of items can be reconstructed. Concretely, this might mean a query parameter for the list at a certain time (time=Xyz). When you paginate, either a cursor-based approach, an offset approach, or a page number approach would all work.

This is not what most human users want: they would see deleted items, wouldn't see added items, and changes to fields you might sort on wouldn't be reflected in the list ordering. But it's ideal for many automated use cases.

ETA: If you're willing to restrict users to a list of undeletable items that is always sorted, ascending, by time of item creation, you can also get by with any strategy for pagination. The last page might get new items appended, and you might get new pages, but any existing pages besides the last page won't change.

[johnisgood]

Someone said he is being downvoted for suggesting cursor-based pagination, yet one of your suggestions was the cursor-based approach, and as thus, I do not understand why he is being down-voted if it is a legitimate approach, which I believe it is.

I guess we would have to hear nebezb's solutions.

If you are already sorting by price and you bookmark at the second page (which now would be in the 3rd), what would you do? I personally do not care about the item in a sorted list enough to expect a bookmarked URL to start from there, or I cannot remember when I did and why. Any ideas why would one want this? If I bookmark second page, I know that the items on page 2 may not always be on page 2. Why would anyone expect different? If you want to bookmark an item, just go to the product itself and bookmark that. I do not think I ever bookmarked a specific page expecting that to never change.

[efitz]

+1000.

There are always trade-offs for architectural decisions.

[oxidant]

Not if the items change relative position over time.

[Zambyte]

archive.org

[tossandthrow]

Well, this really depends on the intention: are you looking for the cheapest items, excluding the 20 first, or are you linking to a content list.

I use Occams razor to decide this, and conceptually it is simpler to think that you are linking to a content list - so that is likely the right answer.

[bravesoul2]

I agree. Most people won't expect urls to provide a wayback-machine style snapshot. Although you could add that as an option "save results as link".

[runeks]

> The example URL here, though, is still not (helpfully) bookmarkable because the contents of page 2 will change as new items are added.

Why is the content changing between refreshes not "(helpfully) bookmarkable"?

The HN front page (ie. "page 1") does that but it's a very useful bookmark.

[purerandomness]

If you're bookmarking a directory, a list of things (e.g. the HN frontpage), you expect the content to change when opening the bookmark.

You bookmark a link to the directory so you don't forget the directory's entry URL.

The use case the author is talking about is a different one: You are configuring a complex item in a shop, and want to bookmark the URL so you can save it, recall it later, share this configuration with someone, or compare it with a different URL.

In this case, you also would expect little details to change (pricing, descriptions, photos) but the structure of the state should stay the same.

It's very frustrating when you share a link to a product detail page, only to discover that all your filters and configurations have been lost.

[Twey]

The data in a bookmark may change, but it should preserve some property of interest — otherwise why bookmark it?

Page 1 (a.k.a. the top few results with no pagination) has the property of being the selected top of HN, which is an interesting property in its own right, and what we're bookmarking. Page 2 doesn't have that property.

[high_na_euv]

Indeed, thats weird.

He probably wants to freeze the state of the page. Maybe he should consider saving it via ctrl s

[crabmusket]

Datomic + put the database version in the URL :)

[waynenilsen]

also significantly better for performance