Support for removal of offset

[danielnc]

Since pagy_cursor is outdated(doesn't work with Pagy 6.0) and last pagy_cursor official release update is from february, are there any plans to support id based pagination(or cursor pagination)?

Offset not only is slow for large tables, but also when using pagy + infinite scroll for reverse ordered elements(for example chat messages) in conjunction with turbo broadcast to render new page elements, it returns duplicated elements(since the offset would not be correct)

If you use last id + limit, instead of offset would solve the problem

What would be the easiest way to either: support removal of offset and relying on last_id of a known rendered element
or overwrite pagy helpers to handle limit/query on my own?

Thanks

[ddnexus]

Hi @danielnc.

Pagy 6 has just been released, so I guess an update of pagy_cursor may follow later, however please, ask in their repo. There are currently no plan to support id/cursor pagination in the pagy core repo, since that would be too dependent on the ORM and pagy is meant to be agnostic.

turbo broadcast to render new page elements, it returns duplicated elements(since the offset would not be correct)

Yeah... I heard @excid3 commenting in a Remote Ruby episode, that in order to avoid the turbo problem with pagination, they don't update the list in their Jumpstart, unless on the first page or something.

infinite scroll for reverse ordered elements

It looks like your app might benefit from fast_page.

overwrite pagy helpers to handle limit/query on my own

I think this short post from @benkoshy may help.

[ddnexus]

https://ddnexus.github.io/pagy/docs/how-to/#paginate-by-id-instead-of-offset

[jclusso]

Can you explain how this gets used. I've added this function but it doesn't do anything since I don't have last_message_id in my params. I'm not exactly sure how I should be overriding the pagination links to add that.

[benkoshy]

This question was asked in the context of an infinite scroll, when you don't want to use offset, for performance reasons. Accordingly, the only pagination link that is required is the "next" link. The first page returns a collection of items. Extract the ID from the last of those items and add that as a param to the relevant controller action.

@ddnexus Please correct me if I'm wrong?

def index   # records_path
   @pagy, @records = pagy_countless(some_scope, ...)
end

@records.each do |record|
# <%=  render record %>
end

link_to("Next page", records_path(last_message_id: @records.last.id) # trigger by clicking or by javascript.

Having said that, if your use case does not involve large numbers of rows, e.g. over a million - consider using the standard pagination (my two cents )

[jclusso]

@benkoshy @ddnexus I see. I'm using Mongoid and just created pagy_mongoid_cursor since I need pagination links. I'm paginating through very large collections. Maybe worth adding to the docs somewhere for anyone looking to do this.

[ddnexus]

Maybe worth adding to the docs somewhere for anyone looking to do this.

Definitely! Thank you.