Empty pages and the calendar extra

[rogermarlow]

I am using the calendar extra for a collection of items which range over about 10 years. Some months contain no items. Should I be able to see that in the styling for the empty months, so the user can jump straight to months with items and not have to click through lots of empty months. Or perhaps not even show the empty months?

[ddnexus]

It's currently not possible to skip months or any other empty units from the calendar bar, and it would be a quite messy looking bar.

One cool feature that I contemplated to implement would be the possibility to disable the links to the empty unit pages, but it looks quite a challenge ATM.

If you can think of an efficient way to do it we could work on it.

[ddnexus]

The problem is not how to make it looks: the problem is checking each page for emptiness... at the moment of creating the nav..

If you can check the results of your query and get an array of boolean values, you could pass it to an overridden nav helper, that would use the disabled HTML markup for the empty pages.

[ddnexus]

ATM you should override the helper in your app, because checking a seldom used extra option right in the core helpers seems a burden for all the apps that don't use it.

That if I can't find an elegant way that costs nothing to the other apps, but... maybe it's doable... I just don't see it ATM.

However your main problem is the previous one. ATM pagy needs to know only how many time units it has to display, knowing NOTHING about their content. If you want to distinguish the pages based on their content then you have to pull that info out of the DB first.

[rogermarlow]

Yes, I don't think this should be in the core. I can certainly work out which months are empty (well, the database will do that for me) Can you point me in the right direction to read about the nav helper?

[ddnexus]

Can you point me in the right direction to read about the nav helper?

It depends on what helper you use. You can do a global search in the gem/lib dir for "def <name-of-helper>" to get the file that defines it

[rogermarlow]

OK, so I override pagy_nav, pass my list of non-empty months in **vars, then as it iterates over the series, for the corresponding items pass a classes: highlight-non-empty argument to the proc returned from the pagy_anchor helper. That will add the highlight class to the relevant anchors. Simples.

[ddnexus]

Yes, that's one way of doing it.

Or you can just use the HTML markup that pagy already uses for disabled links also for empty pages, with the added benefit that they will not be clickable anymore, and eventual readers will be aware of it.

I mean, modify the case condition so it will use a line for empty pages like:

%(<a role="link" aria-disabled="true">#{pagy.label_for(item)}</a>)

[ddnexus]

I just looked at the feature again, and I think it's not that challenging after all 🤓.

It will require an extra query per bar, but the overriding required to get the count of each page/period it's generic enough and it could be added as a short tutorial.

The groupdate gem can make it quite generic. It could probably be chained to the collection scope in the backend.

I think that it could be done by 2 quite simple overrides.

[rogermarlow]

I would be interested to see that solution. I got my approach working although it is quite fiddly. I have to figure out years and months with records inside pagy_calendar_filter and map the years and months to pagy item numbers. That gives me one array for the years nav and another for the months nav which I pass down into my overridden pagy_nav helpers where they use them to decide whether to apply the highlight style to each item.

[ddnexus]

Great!

I will give it a try ASAP. My current theoretical idea will have to work with the actual code so it may end up different, but I am quite confident that it can be quite clean. It might even end up in the gem, but let's see.

[rogermarlow]

Sounds interesting. I am happy to be a test case if you need one.

[ddnexus]

@rogermarlow I've got a bit of time so I started a calendar branch.

I just converted the calendar playground app to a minimal rails app, which use sqlite instead of a mock collection: it will help using groupdate. My time is gone now, but I hope to be able to continue soon.

[ddnexus]

OK, so I started with the goal of including it to the core gem.

The backend part is done. It will add the counts for the period range of each units in the :counts variable. I like the code: it's optional and it doesn't add any complexity, despite my initial concerns.

However, the all featured frontend that I was planning is more complicated than expected. My initial goal was disabling the links to the empty pages. It's a simple feature, but integrating it with the rest of the code would require quite deep core changes that cannot be handled efficiently with automatic overriding (and would go into the regular non-calendar code):

• Each frontend extra disables its links in a different way: that would require different code for each frontend extra
• Disabling pages would require the prev and next links to find the non-empty target page and skip to it

The cons are clearly far beyond the user feedback pros: so no disabled pages.

Removing the empty pages from the bar would solve the above problems, but it would just create a confusing UI IMO, and I suspect it would complicate the internal management of the series and the mapping to the counts. ATM I think it's not convenient, but I would consider it if it's simple.

A quite manageable solution is what I just implemented:

• an added empty-page class for empty pages
• a title attribute that displays the pagy_info for the target page (e.g. "Displaying 123 items").

That just added an automatic override of the pagy_anchor method (when enabled) without any core change.

[rogermarlow]

This might be enough. In my use case I only need a visual indication that the period is empty. Those pages do not have to be removed, or even disabled and next/prev does not have to change behaviour either.

[ddnexus]

@rogermarlow You can try the calendar branch. Missing docs, tests and some stylesheet to target the empty-page classes, but it works.
You can try the new calendar.ru app in that branch.

[rogermarlow]

With the current state of the calendar branch, this implements my use case, using calendar.ru as the example:

--- a/gem/apps/calendar.ru
+++ b/gem/apps/calendar.ru
-  gem 'sqlite3', '~> 1.4.0'
+  gem 'sqlite3', '~> 1.5.0'

+        .empty-page {
+          color: #cbe4ff;
+        }

Which is a lot simpler than what I currently have to do. So, I'd be pleased with that :-)

[ddnexus]

That restriction comes from a previous version of the Activerecord adapter, I don't remember where to search for the new updated requirement.

If you have time, please remove the restriction and install the newest one. When the app runs, AR will raise an error, so you can track what is the current accepted version, so we can update the Gemfiles of the rails apps (and the repo) accordingly.

Thank you

[rogermarlow]

Happy to do so. Unfortunately I have not done gem development before and I am running into some dependency problems. I want to run:

~/github/pagy/gem/apps $ ../bin/pagy ./calendar.ru

but it fails with:

You have already activated rack 2.2.9, but your Gemfile requires rack 3.1.4.

../bin/pagy has an inline gemfile that requires rackup, which depends on rack. That seems to resolve to 3.1.4, presumably because:

~/github/pagy/Gemfile.lock contains
   rack 3.1.4

I do not know how RubyGems resolves the location of gems in inline gemfiles but the error message suggests the Gemfile.lock is where this is coming from.

The question then is why is rack 2.2.9 already activated at this point:

../bin/pagy runs rackup like this:

PAGY_INSTALL_BUNDLE='false' rackup -I ~/github/pagy/gem/lib -r pagy -o 0.0.0.0 -p 8000 -E development calendar.ru

For me, rbenv intercepts this execution of rackup so executes the shim, inside of which we see:
Gem.activate_bin_path('rack', 'rackup', version)
which returns ~/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/rack-2.2.9/bin/rackup

Hence rack 2.2.9 is activated by the rackup invocation and calendar.ru clashes with it.

In summary, why does rack resolve to 3.1.4 in bin/pagy, but when bin/pagy runs rackup with calendar.ru, inside the rackup shim it resolves rack to 2.2.9 ?

[ddnexus]

I think your problem depends on running the pagy launcher directly, instead of using bundle exec pagy from the repo (root dir, better).

That should solve all (or most of) your problems. If that doesn't, then read the Troubleshooting Bundler Inline.

Please, let me know.

[rogermarlow]

No luck on my side getting bundle exec to resolve the conflicts. Nevermind, I see you have things pretty much wrapped up on your side and I don't think I can add anything to this, I am going to abandon my fork. Thanks again for picking up on this idea, and thanks for the gem, it has really helped me out.

[ddnexus]

About the sqlite restriction:

https://github.com/rails/rails/blame/v7.1.3.4/activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb#L14

it looks like it has been stuck there for 5 years and counting!

[ddnexus]

Ruby and e2e tests pass! 🎉
Docs should be OK
Please, let me know if it is understandable.

[rogermarlow]

Yes, the docs make sense to me.

[ddnexus]

The optional empty pages feature has been implemented in v8.5

[rogermarlow]

That's great. Thanks for all your work on this feature and the pagy gem in general.