Using Pagy::Backend outside of a Controller

[excid3]

Hey @ddnexus! 👋

Yesterday, I was working on Madmin to add pagination to has_many associations and needed to add Pagy inside a class outside the controller. I got it working with a small change, but thought I would bring it up as a suggestion that Pagy might consider supporting out of the box.

The gist of it is this:

module Madmin
  class Field
    include Pagy::Backend
    
    def collection(params)
      pagy associated_records, params: params
    end

    # Since we don't have a method or attribute for params, I had to override this:
      def pagy_get_page(vars, force_integer: true)
        params = vars[:params] # Set the local var
        page = params[vars[:page_param] || DEFAULT[:page_param]]
        force_integer ? (page || 1).to_i : page
      end
  end
end

Here's the actual commit in Madmin for more specifics: excid3/madmin@f5c618b#diff-9e38fefc7cbc18013d71df9a04d89ef3c66614ad5521b67d0dd1f74c65db5220R34

Proposal:
Check vars for params key otherwise fallback to params method in Pagy::Backend.

Something like:

      def pagy_get_page(vars, force_integer: true)
        query_params = vars.fetch(:params) { params }
        page = query_params[vars[:page_param] || DEFAULT[:page_param]]
        force_integer ? (page || 1).to_i : page
      end

I imagine this isn't that common (first time I've needed something like this) but it saves me a lot of trouble so I can keep using Pagy::Backend without any changes for compatibility with any future changes.

[ddnexus]

Hi @excid3,
I may miss a lot of things here... so I may say some stupid thing 😬

That said, if instead of passing the params as an extra variable to be extracted and used in the pagy_get_page, you just merge it with the vars (or use it as the vars), the page from your params (now in vars) will set the page and pagy will use it, instead of looking it up in the controller params.

This should do that:

def collection(params)
  pagy associated_records, **params
end

Makes sense?

[excid3]

https://github.com/excid3/madmin/blob/main/app/views/madmin/fields/has_many/_show.html.erb#L1

Basically, with Madmin we have:

1. A resource with attributes
2. Each attribute has a field type
3. The field determines how the attribute is rendered on index, show, and form
4. The field should be the one responsible for the pagination

Bit more complex than your standard controller pagination.

[ddnexus]

ah... then, if I may suggest a clean way, which is also more forward compatible with pagy v10...

def paginated_value(view, record, **) ## allow passing pagy options from the view
  # ...
  collection = value(record)
  view.instance_eval { pagy(collection, page_param: "#{attribute_name}_page", **) }
end

<% pagy, record = field.paginated_value(self, record) %>

HTH

[excid3]

Using the view, wouldn't that be using Pagy::Frontend instead of Pagy::Backend?

[ddnexus]

Ohhh... You are right... I forgot that in v9 all the methods are included in the controller and the code runs searching its own method in the controller...

I am working on v10 since months and v9 is long gone from my mind. Sorry for that. With v9, my suggestion would work only if you add include Pagy::Backend also in the view, since you are calling pagy from the module which is called from the view.

V10 will be properly compartmentalized... you include just a single method: pagy where you use it to paginate anything... then you use the @pagy object to call its instance methods for all the helpers. Super simple, straightforward and no pollution in your code.

You can check the Examples of the README of v10 to see how it will be. (Notice that the README has broken links pointing to the new, not deployed docs)

[excid3]

Oh nice! It should be easy enough to support both once v10 is released.