Should pagination parameters go in URLs?

[eyeseast]

When using the API directly, we use per_page and cursor to manage pagination. Should those get passed through to the frontend?

Upside:

• It makes pagination easier, because those parameters are available in the URL instead of ephemeral state
• Users can link to a specific page, using cursors
• We can change per_page without resetting a search, because we'll have the cursor available

Downside:

• It adds more stuff to the page URL

[allanlasser]

I think this is the right move. Being able to refresh the page you're on, or copy the link to the page you're currently on, seems very useful.

For a use case where this is benefits the user, imagine you're on mobile Safari or using a memory-freeing chrome extension that unloads the browser tab. When the tab is reloaded, the page state is preserved where it left off.

These days browsers don't even show the full URL by default, so I see minimal downside to adding useful query data.

[eyeseast]

For a use case where this is benefits the user, imagine you're on mobile Safari or using a memory-freeing chrome extension that unloads the browser tab. When the tab is reloaded, the page state is preserved where it left off.

This is a really good point. Default Chrome unloads tabs now, so this is going to affect a lot of people.

[duckduckgrayduck]

I agree that this is the right move.

[eyeseast]

Another benefit I just thought of: Putting per_page and cursor in the URL lets us update and rerun the load function just by updating the URL. We shouldn't have to manage the loading lifecycle within the component in parallel.

I'm going to close this as done and open a new issue to finish pagination.

[mitchelljkotler]

I think my only concern is that cursors look much less nice in the URL then a page number. They are also opaque. They also encode the last document on the previous page, so changing the documents in the search (if the document changes or is removed or if users linked to the cursor do not have permission to view it) could result in unexpected behavior. I don't think any of these should prevent them from being stored in the URL though.