Why I can't add HTML class with series_nav

[JasonBarnabe]

https://ddnexus.github.io/pagy/toolbox/helpers/#common-nav-options says I can use the id and aria_label options to set those attributes in the HTML. Why not allow also setting HTML class (and more generally, any HTML attribute)? Pagy AI says I can, but the class does not appear in the HTML.

[ddnexus]

Bootstrap and Bulma nav styles have the classes param that allow you to change/add style-specific classes. That makes sense since - with that styles - pagy produces a html structure understood by that classes.

However I am missing the case about why you would want to add any class to the pagy own HTML structure, when it already has its own classes that you can simply override in your css.

About adding "any HTML attribute"... you can use the anchor_string option.

[JasonBarnabe]

In my specific case, I am switching from will_paginate to pagy, and I want to apply the same styling I already have, which is based on class="pagination". The alternative is to adjust my CSS to duplicate the selectors - not only changing .pagination to .pagination, .pagy, but also .pagination > a to .pagination > a, .pagy > a and all the other more specific selectors I already have.

To put it more generally, the ability to add a class to pagy's div makes it easier to fit it in to the existing CSS framework being used on the site. Potentially there could also be JavaScript and system tests that rely on a specific class being present.

Correct me if I'm wrong, but anchor_string looks like it's added to the links, not the top-level element pagy renders.

[ddnexus]

After adding 'pagination' to pagy html, I suspect you will have the same problem in order to be able to address all the pagy elements, because the HTML is different from what will_paginate generates...

I am very reluctant to add an extra classes argument for pagy because:

• it would be a half-backed "solution" that would still require changes in the user CSS
• it would add code logic to pagy, and to its usage in the user app (with more complexity and maintenance all around)
• it would encourage/officialize a small short-term advantage in exchange for a long-term out-of-sync situation (i.e., the user app would use a kind of half-backed adapter and convoluted code forever, just to avoid a very little extra work at the start)

It might be that, in your specific case, it would magically "fix" everything (and if it does... then your case is simple, and so would be your effort), but would it deserve a pagy feature (which must serve most users, and grant complete solutions)?

Personal note

I ALWAYS prefer to refactor what needs refactoring, instead of trying to add a "patch" here and there to "make it work as before". The only exception might be a hot-fix, but that would be sorted out properly with the highest priority in the very next commit.
I worked on rotten code belonging to organizations embracing that kind of "patching" policy for years. Their policy made their code accumulate technical debt literally for decades, and I can assure you: working in that environment is extremely challenging and stressful. I became quite allergic to it, and even the slightest hint... triggers my strongest immune response. 🤧🤣

[JasonBarnabe]

(pagy.series_nav's and will_paginate's output are structurally very similar, at least in my configuration. The only thing I had to do in addition to duplicating the selectors was dealing with the href-less as. But that's not really the point of this conversation.)

I agree that adding a classes option is not the right solution. But pagy already has id and aria_label options - why are these special? Why not refactor these into a **html_options argument like Rails's link_to or form_tag and allow setting any HTML attribute? Other than class, I can see use cases for dir, lang, style, hidden, data attributes, etc.

This just seemed like a glaring gap in pagy that I thought I'd report it. But in the end, I can live without it, so up to you decide if it'd be useful enough for everyone else.

[ddnexus]

Sure, I really appreciate your point of view, and the mere fact that you have spent your time to contribute to pagy is very valuable to me.

id and aria_label options - why are these special?

Pagy tries to make the life of devs easy, by providing the aria attributes out of the box. However the aria_label is indeed special, in the sense that must be unique in the page, besides as descriptive of its function as possible. A generic "Pages" is ok, but a real world ARIA-friendly app should add more description. Besides having multiple nav labels "Pages" in the same page would produce an invalid HTML document, so pagy must provide the custom argument.

The id is the most specific selector on a page, so omitting that would just cause headache to whoever must deal with a specific nav on the page, so its presence looks self explanatory.

Why not refactor these into a **html_options argument like Rails's link_to or form_tag

Because pagy is not a framework that has to deal with every possible requirement to produce urls, links and forms. That logic is complex and slow and simply unnecessary in a very specialized pagination gem.

Pagy uses extremely bare strings concatenation/interpolation with minimal streamlined logic around it to produce its output. It's ~30x-40x faster and lighter than what you could produce with rails helpers, especially thanks to its minimalistic approach, still offering all the options to be extremely easy and flexible.

dir, lang, style, hidden

You don't need any of that as a pagy user: you can override them in your CSS (and with precision with the id ), or if you really want you can hard-code them in any parent container. (with the style being particularly inconvenient for the user: just pass an id and handle it in your CSS properly).

A pagy nav is something that you just want to drop in a container and expect it will just work with the bare minimum (typically just the collection to paginate). Then you can just customize the pagy CSS with the Pagy Wand or write your own.