Countless pagination includes the last page that was retrieved in Link headers

[JellyPuddy]

Version 43 of pagy changes the way the Link headers look for countless pagination. Instead of just adding a page=1 param to the url, it adds something like page=1+2.
Why is this done, and is there any way to stop pagy from doing this?
I would prefer to have normal link headers that look the same way irregardless of whether I'm using countless pagination.

[ddnexus]

Why is this done[...]?

Countless discovers the pages on the go. The pagy param with the + embeds the latest known page in the param. That supports a few things:

1. It allows the user to click on any previous link without losing the information of the pages discovered so far. E.g.: if you get to page 5 and there is a page 6, and you click on the page 2 link, the page param of the request will be page=2+6, so the nav bar will show 6 pages with the page 2 highlighted as the current page. (Older versions would render the nav bar as 3 total pages)

2. It avoids to use extra params to distinguish different types of pagination, which use different types of page param. Extra params would overcomplicate the code logic, the maintenance, the docs, and the usage in case of param overriding in the app.

and is there any way to stop pagy from doing this?

Why would you care about the value of a param that you don't even have to handle manually?

[JellyPuddy]

Thank you for the explanation, that makes sense

I'm sorry, I didn't really explain well why I was surprised about this parameter. We do not use your frontend components, only the backend part of pagy. So we do handle the link headers manually ourselves in the frontend
We also use the pagy paginator to paginate a public api endpoint, so I feared it might be confusing to people using that api that the link header includes this extra value

[ddnexus]

We also use the pagy paginator to paginate a public api endpoint

In that case you are probably using the :headless option, and in that case it would probably make sense to use only the page value, which would be simple to implement.

What do you think?

[JellyPuddy]

Yes, that makes sense. Sounds good to me!

Thanks for the quick responses

[ddnexus]

Please, try the countless_headless branch and let me know how it works.

[JellyPuddy]

If I do this it still adds the +:

@page, @records = pagy(:countless, headless: true, json)
response.headers.merge!(pagy.headers_hash)

But if I do this it does only return the page number

@page, @records = pagy(:countless, headless: true, json)
response.headers.merge!(pagy.headers_hash(headless: true))

I'm not sure if that is what you intended?
I think if you do this then the first one works too:

-  h[page_key]  = countless? && !options[:headless] ? "#{page || 1}+#{@last}" : page
+  h[page_key]  = countless? && !@options[:headless] ? "#{page || 1}+#{@last}" : page

Also, is it correct that with headless: true I do not get a rel="next" link header? (Sorry if that's a stupid question, I'm not too experienced with pagination)

[ddnexus]

Good catch! The missing @ was a typo 😬

is it correct that with headless: true I do not get a rel="next" link header?

rel="next" is a HTML tag attribute, and it's not a "link header", and since :headless means that you don't use UI helpers... your question confuses me.

[ddnexus]

Oh, right. I forgot tat bit. Sorry.

It's a new feature, so we still have to think it through...

[ddnexus]

Yes, with headless we don't know the last page, so we don't know if we have a next page, so we can't add a rel next.

That means that my feature/idea was not useful for your case.

[JellyPuddy]

That's sad. Any chance that you could add something that would allow me to have countless pagination with all the headers, but without the last visited page in there?
Though I understand that adding an option specifically for that is not very nice, after you've just completely refactored this gem to make it cleaner.

If I must, I could just monkey-patch your gem locally in my codebase, but I'd prefer not to

[ddnexus]

I could just monkey-patch your gem locally in my codebase

That's probably the best option. 🤷

[JellyPuddy]

Then I guess I'll just do that.

Thanks for your time anyway!

[marckohlbrugge]

I had the same issue. At first I thought it was a bug, but then realize it was by design.

I clean up my URLs with wrapper methods that remove the "+last" suffix.

module PaginationHelper
  def pagy_next_url(pagy)
    clean_countless_url(pagy.page_url(:next))
  end

  def pagy_previous_url(pagy)
    clean_countless_url(pagy.page_url(:previous))
  end

  private

  # Remove the "+last" encoding from countless pagination URLs
  # Converts ?page=3+3 to ?page=3
  def clean_countless_url(url)
    return nil if url.nil?

    url.gsub(/page=(\d+)\+\d+/, 'page=\1')
  end
end

[ddnexus]

[ddnexus]

Finally, I got it right.
I refactored the countless paginator to support this. See 43.1.4

You can override the compose_page_param(page) to the :countless paginator and pagy doesn't need to add a new option to just support a deprecated way of pagination.

# Override: support countless legacy url composition and behavior
require 'pagy/classes/offset/countless'
class Pagy
  class Offset
    class Countless < Offset
      def compose_page_param(page) = "#{page || 1}"
    end
  end
end

The last-less param will be generated and used, so you will have also the same legacy behavior: pagy countless will know only if there is a next page to the current, but will have no idea about the last known page.

HTH

[JellyPuddy]

Yes, works like a charm. Thanks!

[ddnexus]

Heads-up: from version 43.2 on, you have to wrap it with: Pagy::EscapedValue.new("#{page || 1}")

[JellyPuddy]

EncodedValue does not seem to exist. Did you mean EscapedValue?

[ddnexus]

Ooops... I need a memory upgrade 🙃. Yes, sorry for the mistake! I will correct the message. Thank you.