Basic Concepts
How To
Migrate WillPaginate/Kaminari
API
Pagy
Pagy::Backend
Pagy::Frontend
Pagy::Countless
Javascript
Extras
Arel
Array
Bootstrap
Bulma
Countless
Elasticsearch Rails
Foundation
Headers
I18n
Items
Overflow
Materialize
Metadata
Navs
Searchkick
Semantic
Support
Tailwind
Trim
UIkit
➡ Chat Support on Gitter ➡
This page tries to cover most of the standard changes you will need to make in order to to migrate from a legacy pagination, however, if the legacy pagination is higly customized you may need more digging into the Pagy documentation.
Feel free to ask on Gitter if you need more assistance.
The Pagy API is quite different from other pagination gems, so there is not always a one-to-one correlation between the changes you will have to make, however, if you split the process in the following general steps it should be quite simple.
In this step you will search statements from legacy pagination gems, remove them and possibly write the equivalent Pagy statements if that makes sense for Pagy:
Notice: Don’t worry about missing something in this step: if anything wont work as before you can fix it later in the process.
gem "pagy"
in the Gemfile
and bundle
, or install and require the gem if you don’t use bundler.include Pagy::Backend
statement to the application controller.include Pagy::Frontend
statement to the application helper.Search for the class name of the pagination gem to migrate from, for example WillPaginate
or Kaminari
. You should find most of the code relative to global gem configuration, or monkey patching.
For example, the following configuration are equivalent:
WillPaginate.per_page = 10
WillPaginate::ViewHelpers.pagination_options[:inner_window] = 4
WillPaginate::ViewHelpers.pagination_options[:outer_window] = 5
Kaminari.configure do |config|
config.max_per_page = 10
config.window = 4
config.outer_window = 5
#config.left = 0
#config.right = 0
end
Pagy::VARS[:items] = 10
Pagy::VARS[:size] = [5,4,4,5]
Remove all the legacy settings of the old gem(s) and uncomment and edit the new settings in the pagy.rb
initializer (see Configuration).
One of the most noticeable difference between the legacy gems and Pagy is that Pagy doesn’t mess at all with the models (read the reasons here).
The other gems are careless about adding methods, scopes, and even configuration settings to them, so you will find different kinds of statements scattered around in your models. You should remove them all and eventually add the equivalent code where it makes sense to Pagy, which of course is absolutely not in the models.
For example, you may want to search for keywords like per_page
, per
and such, which are actually configuration settings. They should either go into the pagy.rb
initializer if they are global to the app, or into the specific pagy
call in the controller if they are specific to an action.
If the app used the page
scope in some of its methods or scopes in some model, that should be removed (including removing the argument used to pass the page number to the method/scope), leaving the rest of the scope in place. Search where the app uses the already paginated scope in the controllers, and use the scope in a regular pagy
statement. For example:
#@records = Product.paginated_scope(params[:page])
@pagy, @records = pagy(Product.non_paginated_scope)
In the controllers, the occurency of statements from legacy pagination should have a one-to-one relationship with the Pagy pagination, so you should be able to go through each of them and convert them quite easily.
Search for keywords like page
and paginate
statements and use the pagy
method instead. For example:
#@records = Product.some_scope.page(params[:page])
#@records = Product.paginate(:page => params[:page])
@pagy, @records = pagy(Product.some_scope)
#@records = Product.some_scope.page(params[:page]).per(15)
#@records = Product.some_scope.page(params[:page]).per_page(15)
#@records = Product.paginate(page: params[:page], per_page: 15)
@pagy, @records = pagy(Product.some_scope, items: 15)
Also in the views, the occurency of statements from legacy pagination should have a one-to-one relationship with the Pagy pagination, so you should be able to go through each of them and convert them quite easily.
Search for keywords like will_paginate
and paginate
statement and use one of the pagy_nav
methods. For example:
<%= will_paginate @records %>
<%= paginate @records %>
<%== pagy_nav @pagy %>
If the app has tests it’s time to run them. If not, start the app and navigate through its pages.
If anything of the old code is still in place you should get some exception. In that case, just remove the old code and retry until there will be no exception.
If the app is working and displays the pagination, it’s time to adjust Pagy as you need, but if the old pagination was using custom items (e.g. custom params, urls, links, html elements, etc.) it will likely not work without some possibly easy adjustment.
Please take a look at the topics in the how-to documentation: that should cover most of your custom needs.
The css styling that you may have applied to the pagination elements may need some minor change. However if the app uses the pagination from bootstrap (or some other framework), the same CSSs should work seamlessly with the pagy nav helpers or with any of the bootstrap templates.
If the app uses I18n
you should follow the I18n doc.