pagy - tail wind extra?

[benkoshy]

Is it a ridiculous idea to add support for a pagy tailwind extra?

Why?

Tailwind is predicated on in-line styles - allowing for easy cusotmisation of css in-line. The current approach is to use add a custom css file pagy.css with tailwind specific styles. This works well enough: yet it feels contrary to the tailwind way of doing this, and becomes tricky if customization is necessary. The following must be altered in order go get customized styling:

.pagy-nav,
.pagy-nav-js {
  @apply flex space-x-2;
}

.pagy-nav .page a,
.pagy-nav .page.active,
.pagy-nav .page.prev.disabled,
.pagy-nav .page.next.disabled,
.pagy-nav-js .page a,
.pagy-nav-js .page.active,
.pagy-nav-js .page.prev.disabled,
.pagy-nav-js .page.next.disabled {
  @apply block rounded-lg px-3 py-1 text-sm text-gray-500 font-semibold bg-gray-200 shadow-md;
  &:hover{
    @apply bg-gray-300;
  }
  &:active{
    @apply bg-gray-400 text-white;
  }
}

.... etc. etc.

How would you customize the above styles, with the pagy_nav template to acheive the desired outcome? Is not a trivial operation IMO.

However, with a tailwind specific extra - and with healthy default options - this allows for a much easier time with customizing specific styling.

What does everyone think?

[ddnexus]

Not sure I get the point of this. Maybe I am missing something here.

How would you customize the above styles, with the pagy_nav template to acheive the desired outcome?

What about using exactly the same CSS, which applies to all pagy output?

How would you write an extra when you actually need a CSS file?

[ddnexus]

Adding this comment as the starting point of the discussion that led to the current implementation.

[benkoshy]

What about using exactly the same CSS, which applies to all pagy output?

The reason I'm suggesting is because: it's not the "tailwind" way. The philosophy is to break away from separate css stylesheets.

It's also difficult / tricky to style / customize - one must apply a style which corresponds to the markup. Without a tool, it's not easy. Perhaps I may write a tool to do the job?

How would you write an extra when you actually need a CSS file?

tailwind uses many utility classes - these could be added in an extra, much like the bootstrap extra, with sensible defaults. The benefit is that it allows for super easy customization, without tooling.

my two cents.

[ddnexus]

The reason I'm suggesting is because: it's not the "tailwind" way.

I thought that @apply was the most amazing tailwind way to override some existing style, as @excid3 explained here, but my knowledge might certainly be outdated. Has @apply been deprecated?

The philosophy is to break away from separate css stylesheets.

We are providing a snippet to paste and customize in your own app. No "separate CSS stylesheet" here, unless you want to. Just a standard override.

It's also difficult / tricky to style / customize - one must apply a style which corresponds to the markup. Without a tool, it's not easy.

I don't see that. You just apply whatever you want to the existing pagy classes that are not going to change (at lest during a major version). You just open the browser dev-tools and inspect interactively what they refer to. I find that very easy, and the users are used to that already. No special documentation to write or learn.

Perhaps I may write a tool to do the job?

Sure, you are welcome to write your own extra and link it to the official pagy repo.
However, unless @apply is officially deprecated, I don't see the need to write, test, document and maintain another core extra ATM.

[bweis]

Just dropping in and voicing my interest in something like this as well. For the time being, I am overriding pagy_nav to get what I want working in a "tailwind-y" way.

[bweis]

Yeah really. When you are used to doing things the "tailwind" way where the css lives adjacent to the actual markup.

This is a quick template I whipped up.

<nav class="flex items-center justify-between border-t border-gray-200 px-4 sm:px-0">
  <div class="-mt-px flex w-0 flex-1">
    <% if pagy_prev_url(pagy) %>
      <%= link_to pagy_prev_url(pagy), :class => 'inline-flex items-center border-t-2 border-transparent pr-1 pt-4 text-sm font-medium text-gray-500 hover:border-gray-300 hover:text-gray-700' do %>
        <svg class="mr-3 h-5 w-5 text-gray-400" viewBox="0 0 20 20" fill="currentColor" aria-hidden="true">
          <path fill-rule="evenodd" d="M18 10a.75.75 0 01-.75.75H4.66l2.1 1.95a.75.75 0 11-1.02 1.1l-3.5-3.25a.75.75 0 010-1.1l3.5-3.25a.75.75 0 111.02 1.1l-2.1 1.95h12.59A.75.75 0 0118 10z" clip-rule="evenodd" />
        </svg>
        Previous
      <% end %>
    <% end %>
  </div>
</div>

<div class="hidden md:-mt-px md:flex">
  <% pagy.series().each do |item| %> <%# series example: [1, :gap, 7, 8, "9", 10, 11, :gap, 36] %>
    <% case item
         when Integer %> <%# link to page %>
      <%= link_to pagy.label_for(item), pagy_url_for(pagy, item), :class => "inline-flex items-center border-t-2 border-transparent px-4 pt-4 text-sm font-medium text-gray-500 hover:border-gray-300 hover:text-gray-700" %>
    <% when String %> <%# current page %>
      <%= link_to pagy.label_for(item), pagy_url_for(pagy, item), :class => "inline-flex items-center border-t-2 border-indigo-500 px-4 pt-4 text-sm font-medium text-indigo-600" %>
    <% when :gap %> <%# gap span %>
      <span class="inline-flex items-center border-t-2 border-transparent px-4 pt-4 text-sm font-medium text-gray-500">…</span>
    <% else %>
      <% raise InternalError, "expected item types in series to be Integer, String or :gap; got #{item.inspect}" %>
    <% end %>
  <% end %>
</div>

<div class="-mt-px flex w-0 flex-1 justify-end">
  <% if pagy_next_url(pagy) %>
    <%= link_to pagy_next_url(pagy), :class => 'inline-flex items-center border-t-2 border-transparent pr-1 pt-4 text-sm font-medium text-gray-500 hover:border-gray-300 hover:text-gray-700' do %>
      Next
      <svg class="ml-3 h-5 w-5 text-gray-400" viewBox="0 0 20 20" fill="currentColor" aria-hidden="true">
        <path fill-rule="evenodd" d="M2 10a.75.75 0 01.75-.75h12.59l-2.1-1.95a.75.75 0 111.02-1.1l3.5 3.25a.75.75 0 010 1.1l-3.5 3.25a.75.75 0 11-1.02-1.1l2.1-1.95H2.75A.75.75 0 012 10z" clip-rule="evenodd" />
      </svg>
    <% end %>
  <% end %>
</div>
</nav>

I had to forgo a bunch of pagy's optimizations and have yet to add back the translations and aria tags, but I am sure that with some basic overrides allowing for class injection you would be able to leverage this. The apply tool only really gets you so far.

Not trying to be argumentative, just trying to show that there is a usecase where we can't easily leverage pagy's current "simple" apis without overriding a bunch of technical/optimized methods, or dropping down to the pagy/extras/pagy module.

[ddnexus]

Not trying to despise anything here, but if that is the "tailwind" way, I REALLY don't like it 🤣

So let me understand what you are suggesting, because I don't see any value in writing and maintaining an extra when you can use the original markup and have NO extra work and NO new mess around.

But besides that there is even a bigger cons.

Right now you have a few lines (that are not repeating at all), that can change whatever you need inside the shortest possible HTML output: just edit the provided css and you are done.

How would hardcoding (the largely repeated) inline classes inside the extra be any better for users that wants to customize it?

[benkoshy]

The apply tool only really gets you so far.

Would be interested if you can elaborate more on this point: what are the limitations for your particular use case?

[bweis]

Not trying to despise anything here, but if that is the "tailwind" way, I REALLY don't like it 🤣

I will absolutely concede that it is an acquired taste. The whole idea is in favor of code-locality and the non-need to name anything. I have found that it really speeds up development and maintaining consistency across a large project. Obviously it is not for everyone.

I don't really think that my ask would be to maintain an extra, but rather to make the pagy_anchor function a bit more composable.

How would hardcoding (the largely repeated) inline classes inside the extra be any better for users that wants to customize it?

If you take a step back from the repeating classes, I think it is more about taking advantage of the markup generation that you have already but allowing for classes to be injected. It looks like that was a thing at some point (haven't dived into the git history) but if you look at frontend.rb you can see the following:

def pagy_anchor(pagy)
  a_string    = pagy.vars[:anchor_string]
  a_string    = %( #{a_string}) if a_string
  left, right = %(<a#{a_string} href="#{pagy_url_for(pagy, PAGE_TOKEN)}").split(PAGE_TOKEN, 2)
  # lambda used by all the helpers
  lambda do |page, text = pagy.label_for(page), classes: nil, aria_label: nil|
    classes    = %( class="#{classes}") if classes
    aria_label = %( aria-label="#{aria_label}") if aria_label
    %(#{left}#{page}#{right}#{classes}#{aria_label}>#{text}</a>)
  end
end

The ability to use the optimized tag generation tools while allowing for users to customize the templating would be much appreciated. See that classes is not able to be specified from my understanding.

Would be interested if you can elaborate more on this point: what are the limitations for your particular use case?

In my example above you can see that in order to get the markup that I preferred I needed to add some additional divs. I am not sure that this is possible without dropping into some :before or :after element weirdness, and even still that is not a solve all.

See a gif of the component in action:

[ddnexus]

See that classes is not able to be specified from my understanding.

Not as a pagy_anchor argument, which would be only embedded in ALL the a tags produced by the lambda (actually you can do that with the :anchor_string), but it is a specific keyword argument available every time you actually use the a lambda, which gives you a lot more power to generate the final HTML anchor.

So I am confused here: you want to be able to be local (which is what you have in the current classes argument), but you are missing a non-local classes argument applied to all the anchors?