Pagy is the ultimate pagination gem that outperforms the others in each and every benchmark and comparison.
Notice: Updating from 2.0+ to 3.0+ requires just some search and replace and a little reorganization of your custom i18n dictionaries. Check the CHANGELOG for details.
Suggestions:
pagy*_nav
helper, consider to switch to pagy*_nav_js
, which gives you the same output with a substancial performance boost.The best way to quickly get an idea about Pagy is comparing it to the other well known gems.
The values shown in the charts below have been recorded while each gem was producing the exact same output in the exact same environment. (see the Detailed Gems Comparison)
Each dot in the visualization above represents the resources that Pagy consumes for one full rendering. The other gems consume hundreds of times as much for the same rendering.
The IPS/Kb ratio is calculated out of speed (IPS) and Memory (Kb): it shows how well each gem uses each Kb of memory it allocates/consumes.
Pagy
class doesn't need to know anything about your models, ORM or storage, so it doesn't add any code to them (see why...)
limit
and offset
(see how...)
Pagy::OverflowError
exceptions that you can rescue from (see how...) or use the overflow extra for a few ready to use common behaviorsAfter installing and including Pagy (see Quick Start), you can use it in a quite familiar way:
Paginate your collection in some controller:
@pagy, @records = pagy(Product.some_scope)
Render the navigation links with a super-fast helper in some view:
<%== pagy_nav(@pagy) %>
Or - if you prefer - render the navigation links with a template:
<%== render partial: 'pagy/nav', locals: {pagy: @pagy} %>
Use the official extras, or write your own in just a few lines. Extras add special options and manage different components, behaviors, Frontend or Backend environments... usually by just requiring them:
ElasticsearchRails
response objectsSearchkick::Results
objectsI18n
gem instead of the pagy-i18n implementationpage=1
param from the first page linkBesides the classic pagination offered by the pagy_nav
helpers, you can use a couple of more performant alternatives:
pagy_nav_js: A faster and lighter classic looking UI, rendered on the client side with optional responsiveness:
pagy_combo_nav_js: The fastest and lightest alternative UI (48x faster, 48x lighter and 2,270x more efficient than Kaminari) that combines navigation and pagination info in a single compact element:
Notice: the pagy_nav_bootstrap
helper used in the screencast has been renamed as pagy_bootstrap_nav
since version 2.0
Pagy follows the Semantic Versioning 2.0.0. Please, check the Changelog for breaking changes introduced by mayor versions.
Pull Requests are welcome!
Before spending time creating a (potentially complex) Pull Request, you can Confirm on Gitter whether your proposed changes are going to be useful for most users.
If you Create A Pull Request, please ensure that the "All checks have passed" indicator gets green light on the Pull Request page. That means that the tests passed and Codecov and Rubocop are happy.
The master
branch is the latest rubygem-published release. It also contains docs and comment changes that don't affect the published code.
The dev
branch is the development branch with the new code that will be merged in the next release.
Expect any other branch to be experimental, force-rebased and/or deleted even without merging.
Many thanks to:
One of the latest jruby version (9.2.+) raises a couple of random Java::JavaLang::NullPointerException
while running the frontend tests in Travis. That doesn't happen with previous versions.
It might be just another jruby bug or a number of possible things related to the tests or the Travis build that might or might not affect real usage. I am done with debugging jruby weirdness, so I am not going to investigate it further. If you get any info about it, please, create an issue.
This project is available as open source under the terms of the MIT License.