Revise pagination item calculation

[robertknight]

Revise how the pagination items (page numbers and elided page markers) are calculated, such that the number of items rather than the number of numbered pages remains consistent as the user navigates through the list. Provided each item is rendered with a roughly consistent width, this keeps the overall width of the control and the position of child components consistent when navigating through the list.

When this middle controls have a consistent width, the Pagination also works better in cases where the Prev/Next controls are adjacent to the middle items, rather than aligned with the edge of the content area above (the table here).

Testing:

Go to http://localhost:4001/navigation-pagination, navigate through the list. Observe that the number of items displayed is the same regardless of current page. Compare with https://patterns.hypothes.is/navigation-pagination where this is not the case.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (5c82a76) to head (f96444c).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #1829   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           70        70           
  Lines         1272      1303   +31     
  Branches       477       482    +5     
=========================================
+ Hits          1272      1303   +31     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[robertknight]

The test above checks a few specific examples against expected results. The test below is a property test that generates a range of configurations and for each verifies that certain properties are satisfied for every possible current page.

[robertknight]

"strictly increasing" as in "a strictly increasing function"

[acelaya]

The algorithm is maybe not super easy to understand at a glance, but it does bring the benefits you describe here, and the new tests help a lot documenting it.

[acelaya]

This test is great, because it helps document the functionality, which is pretty complex.

However, it made me realize that, considering the elision in a 6-page pagination ([1, null, 3, 4, 5, 6]), I would have expected no elided pages for a 4-page pagination ([1, 2, 3, 4]) regardless of current page, but it seems we do elide ([1, 2, null, 4]).

Can you explain the algorithm to me as if I were a five-year-old 😅?

[robertknight]

In prose:

1. If there is one page, return an empty list
2. Calculate if there are elided pages before the current page
3. If no, create a list of all pages before the current page. If yes, create a list of the pages before the elided range, then null, then pages after the elided range.
4. Add the current page to the list
5. Calculate if there are elided pages after the current page
6. If no, append all pages after the current page. If yes, append a list of pages after the current page, before the elided range, then null, then pages after the elided range
7. Calculate the maximum number of items we might show, for all possible values of the current page
8. While the current number of items in the list is less than the maximum, expand the list by inserting an extra page number and "shrinking" the elided range. We preferentially take the page numbers from the elided range after the current page, but if that is empty, take them from the elided numbers before the current range.