Hey Ben, I didn't use that because I was not sure it would fit with the current way I use master. I push commits that are just doc or test that don't require the release, but do require to be in master. Wouldn't that trigger a release push?
I'm quite confident it can be customized to suit your workflow. e.g. publishing to ruby gems only when you add a tag which begins with "v4.0.01". I will have a look further, it looks interesting. please let me know if this will be more beneficial, or if it complicates things. my goal is to make it slightly easier for you, not more difficult.
Hello 👋 everyone!
I'm setting the size: [1, 1, 1, 1] to my pagy and the total calculated pages are 9 and when I go to the 4th page (also happens when I go to the 6th page) I get this series: [1, 2, 3, "4", 5, :gap, 9]. As I specified in my size param I want 1 before the current_page but I'm getting 2 pages. My expected output is series: [1, :gap, 3, "4", 5, :gap, 9] Am I doing something wrong?
I do get my expected output when I go to the 5th page: series: [1, :gap, 4, "5", 6, :gap, 9]
Thank you for your help.
... when the gap is exactly one page, so instead of a very useless ..., pagy puts the otherwise missing link to the page. When there are 2 or more missing pages, then the gap makes sense.
2 replies
I just noticed when using Pagy, my app was always doing a full SELECT posts.* despite using fragment caching. I would expect it do only do a full SELECT on the first request, and on subsequent request do a faster SELECT COUNT(*) AS "size", MAX(subquery_for_cache_key.collection_cache_key_timestamp) AS timestamp FROM (SELECT … and then use the cached fragment instead.
After some digging, I realized it's because the Countless extra does a .to_a on the collection in order to see if there are further pages. I don't know if there's a way around that, but I thought it would be worth mentioning on the https://ddnexus.github.io/pagy/api/countless.html#caveats page so people are aware of this. What do you think @ddnexus ?
COUNT(*) query, and just accept that Pagy doesn't know whether there's a next page? Because I'm using infinite scrolling, I don't mind it trying to load an empty page. It can just assume there's a next page, and so eventually it will just load a page without any items. That's fine
Okay seems to work really well! The only two gotchas I ran into are:
1) @pagy.next? no longer working. But it makes sense. I guess I was expecting it to just always return true, which would make it easier to migrate between the two countless modes. But I can also see how that might be confusing to some users. For now I just check if the current @posts is present. In which case I assume there will be another page. When we finally request a page where @posts is empty, then we won't render a next page link anymore.
2) @pagy.next to get the next page number didn't work anymore. So I had to create my own variable based on params[:page], defaulting to 1 if blank, and incrementing it. I feel like this could still be something Pagy could provide, even in the minimal mode.
Neither are a big issue tho
@pagy.next?no longer working
That never worked: that's not even a pagy method :)
@pagy.nextto get the next page number didn't work anymore
Pagy variables are either known for certain or nil. Setting next to the next page (that is not known unless you query the DB) would violate that principle or defeat the purpose of the countless_minimal mode.
So I had to create my own variable based on
params[:page], defaulting to1if blank
You don't need that: pagy does it for you. Just use @pagy.page.
My average response time is now 23% faster
HTH
@pagy.page is helpful to know. Thanks!
<div class="d-flex justify-content-center"> <%== pagy_bootstrap_nav(@pagy_a) %> </div> - i've been using something like this. you can even create a helper method to display the above if you want