Regression from changing pagy_link_proc to pagy_anchor in pagy 8.X?

[nickjj]

In pagy 6.X I had code that looked like this:

<% anchor_extras = anchor ? "data-controller=\"anchor\" data-anchor-name-value=\"#{anchor}\" data-action=\"anchor#scroll\"" : "" -%>
<% link = pagy_link_proc(pagy, link_extra: "data-turbo-action=\"advance\"#{anchor_extras}") -%>

In pagy 8.X it says pagy_link_proc has been renamed to pagy_anchor but link_extra has been removed with no replacement.

How can we accomplish the same thing with 8.X? Thanks.

[nickjj]

Thanks. That page mentions a.(page_number, text, classes:, aria_label:) but how would you set data attributes when it's not a supported argument? Technically I'm able to get it work by customizing https://ddnexus.github.io/pagy/docs/how-to/#customize-the-link-attributes but this will mean adding a very long string of data attributes to dozens of controllers where as previously I was able to define it once in the pagy partial.

[ddnexus]

@nickjj The old system was messy because it was allowing to add up strings after strings at all levels. It was also inefficient and ugly looking.

The new system moved the control of the now anchor_string to the pagy instance itself, which solved all the problems above, besides being quite simple to implement and maintain.

However, it's mostly frontend logic, and looking at it now... it feels misplaced in the pagy instance.

It should be a helper argument, passed down to the pagy_anchor, but that raises the problem of the default.

The defaults go in the instance automatically and for consistency would need to be merged with the eventual anchor_string that would be also assignable at instance creation, or to the helper and to the pagy_anchor, which seems quite similar to the old messy system that we just get rid of (with the exception of adding up instead of replacing strings)

@benkoshy @nickjj So what about removing the DEFAULT[:anchor_string] all together? I am thinking about stuff like data-remote="true" that would benefit from it... is there still anything like that in rails 7?

[benkoshy]

Apologies @nickjj - I was incorrect in my original posting of the link above. and you are correct on that.

• Rails 7 canonically uses Turbo. All turbo requests, by default are basically ajax requests. i.e. data-remote='true'
• re: So what about removing the DEFAULT[:anchor_string] all together I cannot see that there is any need for a default to be set. If any one does need defaults, perhaps it can be handed in some sort of factory method? Given an escape hatch does exist i reckon DEFAULT[:anchor_string] can be safely removed.
• Canonically i would see use cases posed by @nickjj quite common - where stimulus JS and other attributes may be passed into pagination links and if anchor_string / link_extra (however you call it) were handled in the front_end via helper argument, that would probably be very well received by the community.

[ddnexus]

Thank you @benkoshy!

I was looking for other seemingly misplaced pagy variables... and I've found that also the URL :fragment that goes into the links, is quite weird in the pagy instance. It is part of the view of the page that the link will hit, so I should move it into the helpers.

On the other hand the :request_path - that also goes into the URLs - is more a backend thing, so it seems to make sense in the controller, and not in the view.

Thoughts?

[nickjj]

I am thinking about stuff like data-remote="true" that would benefit from it... is there still anything like that in rails 7?

I'd probably stay away from setting things like this by default because Rails has been and is moving towards using Hotwire Turbo where folks may or may not be using Turbo Frames which has different attributes. That's why I added that turbo action advanced property, it's to support pagination inside of a Turbo Frame but not everyone would do that on every page.

[ddnexus]

I put the changes for :anchor_string and :fragment in the branch 9 because they are breaking changes. You can try them.

[nickjj]

Thanks a lot for adding this. Based on how it's documented this will work in the same way as before but with a new name.

[ddnexus]

this will work in the same way as before but with a new name

It may look like so on the outside and it's true for the specific way you are using it, but it's very different in concept and code internally.

No addition of strings at 4 levels (default, instance, proc definition and proc execution), but overriding of the same string at 2 levels focused on the same topic (helper argument and proc definition argument inside the helper). A lot cleaner logic and code, a lot simpler and more efficient, and not error prone as before.

[nickjj]

Just for completion's sake. I did start referencing this gem from branch 9 and it's working as expected.

[ddnexus]

Great, thank you for the info!

Just to be safe, if you use it in production/live, please fork it and reference the commit in your fork, because the branch could be force pushed in the near future or might contain temporary bugs introduced by refactoring/new features, and it might break your live app. Referencing the commit in your fork would avoid all that.

Thanks

[nickjj]

Yep for sure, it's currently an app in development so I have time before forking.