# How To

This page contains the practical tips and examples to get the job done with Pagy. If there is something missing, or some topic that you think should be added, fixed or explained better, please open an issue.

# Control the items per page

You can control the items per page with the items variable. (Default 20)

You can set its default in the pagy.rb initializer (see How to configure pagy). For example:

pagy.rb (initializer)
Pagy::DEFAULT[:items] = 25

You can also pass it as an instance variable to the Pagy.new method or to the pagy controller method:

@pagy, @records = pagy(Product.some_scope, items: 30)

See also a couple of extras that handle the :items in some special way:

  • gearbox: Automatically change the number of items per page depending on the page number
  • items: Allow the client to request a custom number of items per page with an optional selector UI

# Control the page links

You can control the number and position of the page links in the navigation through the :size variable.

# Simple nav

You can set the :size variable to a single positive Integer to represent the total number of page links rendered. The current page will be placed as centered as possible in the series.

For example:

pagy = Pagy.new(count: 1000, page: 10, size: 5)
pagy.series
#=> [8, 9, "10", 11, 12]
pagy = Pagy.new(count: 1000, page: 2, size: 5)
pagy.series
#=> [1, "2", 3, 4, 5]
pagy = Pagy.new(count: 1000, page: 99, size: 5)
pagy.series
#=> [96, 97, 98, "99", 100]

Setting the :size variable as a single integer has a few advantages over the classic way. It uses a simpler and faster algorithm, the series length is more constant, cleaner and less confusing to the user. On the other hand it does not allow the user to jump to the first or last page of a long series, which may or may not be a limitation. For example: with a navigation using Pagy::Countless or Calendar it is a clear advantage.

# Classic nav

You can set the :size variable to an array of 4 integers in order to specify which and how many page links to show.

The default is [1,4,4,1], which means that you will get 1 initial page, 4 pages before the current page, 4 pages after the current page, and 1 final page.

As usual you can set the :size variable as a global default by using the Pagy::DEFAULT hash or pass it directly to the pagy method.

The navigation links will contain the number of pages set in the variables:

size[0]...size[1] current page size[2]...size[3] - e.g.:

pagy = Pagy.new count: 1000, page: 10, size: [3, 4, 4, 3] # etc
pagy.series
#=> [1, 2, 3, :gap, 6, 7, 8, 9, "10", 11, 12, 13, 14, :gap, 48, 49, 50]

As you can see by the result of the series method, you get 3 initial pages, 1 :gap (series interrupted), 4 pages before the current page, the current :page (which is a string), 4 pages after the current page, another :gap and 3 final pages.

You can easily try different options (also asymmetrical) in a console by changing the :size. Just check the series array to see what it contains when used in combination with different core variables.

# Skip the page links

If you want to skip the generation of the page links, just set the :size variable to an empty array:

pagy = Pagy.new count: 1000, size: [] # etc
pagy.series
#=> []

# Customize the series

If changing the :size is not enough for your requirements (e.g. if you need to add intermediate segments or midpoints in place of gaps) you should override the series method. See more details and examples here.

# Pass the page number

You don't need to explicitly pass the page number to the pagy method, because it is pulled in by the pagy_get_vars (which is called internally by the pagy method). However you can force a page number by just passing it to the pagy method. For example:

controller
@pagy, @records = pagy(my_scope, page: 3) # force page #3

That will explicitly set the :page variable, overriding the default behavior (which usually pulls the page number from the params[:page]).

# Customize the dictionary

Pagy composes its output strings using standard i18n dictionaries. That can be used to change the language and customize your specific app.

Default en dictionary
# English default 118n dictionary
en:
  pagy:
    aria_label:
      nav:
        one: "Page"
        other: "Pages"
      previous: "Previous"
      next: "Next"
    prev: "<"
    next: ">"
    gap: "…"
    item_name:
      one: "item"
      other: "items"
    info:
      no_items: "No %{item_name} found"
      single_page: "Displaying <b>%{count}</b> %{item_name}"
      multiple_pages: "Displaying %{item_name} <b>%{from}-%{to}</b> of <b>%{count}</b> in total"
    combo_nav_js: "<label>Page %{page_input} of %{pages}</label>"
    items_selector_js: "<label>Show %{items_input} %{item_name} per page</label>"

If you are ok with the default supported locale dictionaries just refer to Pagy::I18n.

If you want to customize the translations or some specific output, you should edit the relevant entries in the pagy dictionary.

If you explicitly use the i18n extra, override the pagy target entries in your own custom dictionary (refer to the I18n official documentation).

If you don't use the above extra (and rely on the pagy faster code) you can copy and edit the dictionary files that your app uses and configure pagy to use them.

pagy.rb (initializer)
# load the "en" and "de" locale defined in the custom files at :filepath:
Pagy::I18n.load({ locale: 'de', filepath: 'path/to/my-custom-de.yml' },
                { locale: 'en', filepath: 'path/to/my-custom-en.yml' })

# Example of custom dictionary

You may want to customize the output of a few entries, leaving the other entries in place:

Custom en dictionary
# English custom 118n dictionary
en:
  pagy:
    aria_label:
      nav:
        one: "Page"
        other: "Pages"
      previous: "Previous"
      next: "Next"
    prev: "&lt;"
    next: "&gt;"
    gap: "&hellip;"
    item_name:
      one: "item"
      other: "items"
    info:
      no_items: "0 of 0"                            # customized
      single_page: "%{count} of %{count}"           # customized
      multiple_pages: "%{from}-%{to} of %{count}"   # customized
    combo_nav_js: "<label>Page %{page_input} of %{pages}</label>"
    items_selector_js: "<label>Show %{items_input} %{item_name} per page</label>"

# Customize the ARIA labels

You can customize the aria-label attributes of all the pagy helpers by passing either the :nav_aria_label string itself or the :nav_i18n_key (See pagy_nav)

You can also replace the pagy.aria_label.nav strings in the dictionary, as well as the pagy.aria_label.previous and the pagy.aria_label.next.

See more details in the ARIA attributes Page.

# Customize the page param

Pagy uses the :page_param variable to determine the param it should get the page number from and create the URL for. Its default is set as Pagy::DEFAULT[:page_param] = :page, hence it will get the page number from the params[:page] and will create page URLs like ./?page=3 by default.

You may want to customize that, for example to make it more readable in your language, or because you need to paginate different collections in the same action. Depending on the scope of the customization, you have a couple of options:

  1. Pagy::DEFAULT[:page_param] = :custom_param will be used as the global default
  2. pagy(scope, page_param: :custom_param) or Pagy.new(count:100, page_param: :custom_param) will be used for a single instance (overriding the global default)

You can also override the pagy_get_vars if you need some special way to get the page number.

# Customize the link attributes

If you need to customize some HTML attribute of the page links, you may not need to override the pagy_nav* helper. It might be enough to pass some extra attribute string with the :link_extra variable. For example:

# for all the Pagy instances
Pagy::DEFAULT[:link_extra] = 'data-remote="true" class="my-class"'

# for a single Pagy instance (if you use the Pagy::Backend#pagy method)
@pagy, @records = pagy(my_scope, link_extra: 'data-remote="true" class="my-class"')

# or directly to the constructor
pagy = Pagy.new(count: 1000, link_extra: 'data-remote="true" class="my-class"')

# or from a view: e.g.:
< %== pagy_bootstrap_nav(@pagy, link_extra: 'data-action="hello#world"') % > 

# Customize the params

When you need to add some custom param or alter the params embedded in the URLs of the page links, you can set the variable :params to a Hash of params to add to the URL, or a Proc that can edit/add/delete the request params.

If it is a Proc it will receive the key-stringified params hash complete with the page param and it should return a possibly modified version of it.

An example using except and merge!:

controller
@pagy, @records = pagy(collection, params: ->(params) { params.except('not_useful').merge!('custom' => 'useful') })

You can also use the :fragment variable to add a fragment the URLs of the pages:

controller
@pagy, @records = pagy(collection, fragment: '#your-fragment')

# Customize the URL

When you need something more radical with the URL than just massaging the params, you should override the pagy_url_for right in your helper.

The following are a couple of examples.

# Enable fancy-routes

The following is a Rails-specific alternative that supports fancy-routes (e.g. get 'your_route(/:page)' ... that produce paths like your_route/23 instead of your_route?page=23):

controller

def pagy_url_for(pagy, page, absolute: false)
  params = request.query_parameters.merge(pagy.vars[:page_param] => page, only_path: !absolute)
  url_for(params)
end

# POST with page links

You may need to POST a very complex search form that would generate an URL potentially too long to be handled by a browser, and your page links may need to use POST and not GET. In that case you can try this simple solution:

controller

def pagy_url_for(_pagy, page, **_)
  page
end

That would produce links that look like e.g. <a href="2">2</a>. Then you can attach a javascript "click" event on the page links. When triggered, the href content (i.e. the page number) should get copied to a hidden "page" input and the form should be posted.

For a broader tutorial about this topic see Handling Pagination When POSTing Complex Search Forms by Ben Koshy.

# Customize the item name

The pagy_info and the pagy_items_selector_js helpers use the "item"/"items" generic name in their output. You can change that by editing the values of the "pagy.item_name" i18n key in the dictionary files that your app is using.

Besides you can also (dynamically) set the :item_i18n_key variable to let Pagy know where to lookup the item name in some dictionary file (instead of looking it up in the default "pagy.item_name" key).

You have a few ways to do that:
  1. you can override the pagy_get_vars method in your controller, adding the dynamically set :item_i18n_key. For example with ActiveRecord (mostly useful with the i18n extra or if you copy over the AR keys into the pagy dictionary):
controller

def pagy_get_vars(collection, vars)
  { count:         ...,
    page:          ...,
    item_i18n_key: "activerecord.models.#{collection.model_name.item_i18n_key}" }.merge!(vars)
end
  1. you can set the :item_i18n_key variable, either globally using the Pagy::DEFAULT hash or per instance with the Pagy.new method or with the pagy controller method:
initializer (pagy.rb)
# all the Pagy instances will have the default
Pagy::DEFAULT[:item_i18n_key] = 'activerecord.models.product'

# or single Pagy instance
@pagy, @record = pagy(my_scope, item_i18n_key: 'activerecord.models.product')

or passing it as an optional keyword argument to the helper:

View
<%== pagy_info(@pagy, item_i18n_key: 'activerecord.models.product') %>
<%== pagy_items_selector_js(@pagy, item_i18n_key: 'activerecord.models.product') %>
  1. you can override entirely the :item_name by passing an already pluralized string directly to the helper call:
View
<%== pagy_info(@pagy, item_name: 'Product'.pluralize(@pagy.count)) %>
<%== pagy_items_selector_js(@pagy, item_name: 'Product'.pluralize(@pagy.count)) %>

# Customize CSS styles

For all its own interactive helpers the pagy gem includes a few stylesheets that you can customize.

Besides that, pagy provides a few frontend extras for bootstrap, bulma, foundation, materialize, semantic, tailwind and uikit that come with a decent styling provided by their respective framework.

If you need to further customize the styles provided by the extras, in most you don't necessary need to override the helpers: here are a few alternatives:

  • Check wether the specific extra offers customization (e.g. bulma)
  • Define the CSS styles to apply to the pagy CSS classes
  • If sass/scss is available: extend the pagy CSS classes with some framework defined class, using the @extend sass/scss directive
  • Use the jQuery addClass method
  • Use a couple of lines of plain javascript

# Override pagy methods

You include the pagy modules in your controllers and helpers, so if you want to override any of them, you can redefine them right in your code, where you included them.

You can read more details in the nice How to Override pagy methods only in specific circumstances mini-post by Ben Koshy.

Also, consider that you can use prepend if you need to do it globally:


module MyOverridingModule
  def pagy_any_method
    #...
    super
    #...
  end
end
Pagy::Backend.prepend MyOverridingModule
# and/or
Pagy::Frontend.prepend MyOverridingModule

# Paginate an Array

See the array extra.

# Paginate ActiveRecord collections

Pagy works out of the box with ActiveRecord collections. See also the arel extra for better performance of grouped ActiveRecord collections.

# Paginate a decorated collection

Do it in 2 steps: first get the page of records without decoration, and then apply the decoration to it. For example:

controller
@pagy, records     = pagy(Post.all)
@decorated_records = records.decorate # or YourDecorator.method(records) whatever works

# Custom count for custom scopes

Your scope might become complex and the default pagy collection.count(:all) may not get the actual count. In that case you can get the right count in a couple of ways:

controller
# Passing the right arguments to the internal `collection.count(...)` (See the ActiveRecord documentation for details)
@pagy, @records = pagy(custom_scope, count_args: [:join])

# or directly pass the right count to pagy (that will directly use it skipping its own `collection.count(:all)`)
@pagy, @records = pagy(custom_scope, count: custom_count)

# Paginate a grouped collection

For better performance of grouped ActiveRecord collection counts, you may want to take a look at the arel extra.

# Paginate for generic API clients

When your app is a service that doesn't need to serve any UI, but provides an API to some sort of client, you can serve the pagination metadata as HTTP headers added to your response.

In that case you don't need the Pagy::Frontend nor any frontend extra. You should only require the headers extra and use its helpers to add the headers to your responses.

# Paginate with JSON:API

See the jsonapi extra.

# Paginate for Javascript Frameworks

If your app uses ruby as pure backend and some javascript frameworks as the frontend (e.g. Vue.js, react.js, ...), then you may want to generate the whole pagination UI directly in javascript (with your own code or using some available javascript module).

In that case you don't need the Pagy::Frontend nor any frontend extra. You should only require the metadata extra and pass the pagination metadata in your JSON response.

# Paginate Ransack results

Ransack result returns an ActiveRecord collection, which can be paginated out of the box. For example:

controller
q              = Person.ransack(params[:q])
@pagy, @people = pagy(q.result)

# Paginate search framework results

Pagy has a few of extras for gems returning search results:

# Paginate by id instead of offset

With particular requirements/environment an id-based pagination might work better than a classical offset-based pagination, You can use an interesting approach proposed here.

# Paginate by date instead of a fixed number of items

Use the calendar extra that adds pagination filtering by calendar time unit (year, quarter, month, week, day).

# Paginate multiple independent collections

By default pagy tries to derive parameters and variables from the request and the collection, so you don't have to explicitly pass it to the pagy* method. That is very handy, but assumes you are paginating a single collection per request.

When you need to paginate multiple collections in a single request, you need to explicitly differentiate the pagination objects.

# Pass the request path

By default pagy generates its links reusing the same request_path of the request, however if you want to generate links pointing to a different controller/path, you should explicitly pass the targeted :request_path. For example:

# Separate turbo frames actions

If you're using hotwire (turbo-rails being the Rails implementation), another way of maintaining independent contexts is using separate turbo frames actions. Just wrap each independent context in a turbo_frame_tag and ensure a matching turbo_frame_tag is returned:

  <-- movies/index.html.erb -->
  
  <-- movies#bad_movies -->
  <%= turbo_frame_tag "bad_movies", src: bad_movies_path do %>    
      <%= render "movies_table", locals: {movies: @movies}%>
      <%== pagy_bootstrap_nav(@pagy) %>    
  <% end %>

  <-- movies#good_movies -->
  <%= turbo_frame_tag "good_movies", src: good_movies_path  do %>    
      <%= render "movies_table", locals: {movies: @movies}%>
      <%== pagy_bootstrap_nav(@pagy) %>    
  <% end %>   
  # controller action 
def good
  @pagy, @movies = pagy(Movie.good, items: 5)
end

def bad
  @pagy, @movies = pagy(Movie.bad, items: 5)
end 

Consider Benito Serna's implementation of turbo-frames (on Rails) using search forms with the Ransack gem along with a corresponding demo app for a similar implementation of the above logic.

# Using different page_param(s)

You can also paginate multiple model in the same request by simply using multiple :page_param:


def index # controller action
  @pagy_stars, @stars     = pagy(Star.all, page_param: :page_stars)
  @pagy_nebulae, @nebulae = pagy(Nebula.all, page_param: :page_nebulae)
end

# Wrap existing pagination with pagy_calendar

You can easily wrap your existing pagination with the pagy_calendar method. Here are a few examples adding :year and :month to different existing statements.

controller
# pagy without calendar
@pagy, @record = pagy(collection, any_vars: value, ...)
# wrapped with pagy_calendar
@calendar, @pagy, @records = pagy_calendar(collection, year: { ... },
                                           month:            { ... },
                                           pagy:             { any_vars: value, ... })

# any other backend constructors (e.g. pagy_searchkick)
@pagy, @record = pagy_searchkick(pagy_search_args, any_vars: value, ...)
# wrapped with pagy_calendar
@calendar, @pagy, @records = pagy_calendar(pagy_search_args, year: { ... },
                                           month:                  { ... },
                                           pagy:                   { backend:  :pagy_searchkick,
                                                                     any_vars: value, ... })

Then follow the calendar extra documentation for more details.

# Paginate pre-offset and pre-limited collections

With the other pagination gems you cannot paginate a subset of a collection that you got using offset and limit. With Pagy it is as simple as just adding the :outset variable, set to the initial offset. For example:

controller
subset                   = Product.offset(100).limit(315)
@pagy, @paginated_subset = pagy(subset, outset: 100)

Assuming the :items default of 20, you will get the pages with the right records you are expecting. The first page from record 101 to 120 of the main collection, and the last page from 401 to 415 of the main collection. Besides the from and to attribute readers will correctly return the numbers relative to the subset that you are paginating, i.e. from 1 to 20 for the first page and from 301 to 315 for the last page.

# Paginate non-ActiveRecord collections

The pagy_get_vars method works out of the box with ActiveRecord collections; for other collections (e.g. mongoid, etc.) you might want to change the :count_args default to suite your ORM count method:

pagy.rb (initializer)
Pagy::DEFAULT[:count_args] = []

or in extreme cases you may need to override it in your controller.

# Paginate collections with metadata

When your collection is already paginated and contains count and pagination metadata, you don't need any pagy* controller method. For example this is a Tmdb API search result object, but you can apply the same principle to any other type of collection metadata:

#<Tmdb::Result page=1, total_pages=23, total_results=446, results=[#<Tmdb::Movie ..>,#<Tmdb::Movie...>,...]...>

As you can see it contains the pagination metadata that you can use to setup the pagination with pagy:

controller
# get the paginated collection
tobj = Tmdb::Search.movie("Harry Potter", page: params[:page])
# use its count and page to initialize the @pagy object
@pagy = Pagy.new(count: tobj.total_results, page: tobj.page)
# set the paginated collection records
@movies = tobj.results

# Paginate Any Collection

Pagy doesn't need to know anything about the kind of collection you paginate. It can paginate any collection, because every collection knows its count and has a way to extract a chunk of items given a start/offset and a per-page/limit. It does not matter if it is an Array or an ActiveRecord scope or something else: the simple mechanism is the same:

  1. Create a Pagy object using the count of the collection to paginate
  2. Get the page of items from the collection using the start/offset and the per-page/limit (pagy.offset and pagy.items)

Here is an example with an array. (Please, notice that this is only a convenient example, but you should use the array extra to paginate arrays).

# paginate an array
arr = (1..1000).to_a

# Create a Pagy object using the count of the collection to paginate
pagy = Pagy.new(count: arr.count, page: 2)
#=> #<Pagy:0x000055e39d8feef0 ... >

# Get the page of items using `pagy.offset` and `pagy.items`
paginated = arr[pagy.offset, pagy.items]
#=> [21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40]

This is basically what the pagy method included in your controller does for you in one go:

controller
@pagy, @products = pagy(Product.some_scope)

Then of course, regardless the kind of collection, you can render the navigation links in your view:

view
<%== pagy_nav(@pagy) %>

See the Pagy::Backend source and the Pagy::Backend API documentation for more details.

# Use the pagy_nav* helpers

These helpers take the Pagy object and return the HTML string with the pagination links, which are wrapped in a nav tag and are ready to use in your view. For example:

view
<%== pagy_nav(@pagy) %>
Extra Helpers
bootstrap pagy_bootstrap_nav, pagy_bootstrap_nav_js, pagy_bootstrap_combo_nav_js
bulma pagy_bulma_nav, pagy_bulma_nav_js, pagy_bulma_combo_nav_js
foundation pagy_foundation_nav, pagy_foundation_nav_js, pagy_foundation_combo_nav_js
materialize pagy_materialize_nav, pagy_materialize_nav_js, pagy_materialize_combo_nav_js
navs pagy_nav_js, pagy_combo_nav_js
semantic pagy_semantic_nav, pagy_semantic_nav_js, pagy_semantic_combo_nav_js
uikit pagy_uikit_nav, pagy_uikit_nav_js, pagy_uikit_combo_nav_js

If you need to override a pagy_nav* helper you can copy and paste it in your helper and edit it there. It is a simple concatenation of strings with a very simple logic.

Depending on the level of your overriding, you may want to read the Pagy::Frontend API documentation for complete control over your helpers.

# Skip single page navs

Unlike other gems, Pagy does not decide for you that the nav of a single page of results must not be rendered. You may want it rendered... or maybe you don't. If you don't... wrap it in a condition and use the pagy_nav* only if @pagy.pages > 1 is true. For example:

<%== pagy_nav(@pagy) if @pagy.pages > 1 %>

# Skip page=1 param

By default Pagy generates all the page links including the page param. If you want to remove the page=1 param from the first page link, just require the trim extra.

# Deal with a slow collection COUNT(*)

Every pagination gem needs the collection count in order to calculate all the other variables involved in the pagination. If you use a storage system like any SQL DB, there is no way to paginate and provide a full nav system without executing an extra query to get the collection count. That is usually not a problem if your DB is well organized and maintained, but that may not be always the case.

Sometimes you may have to deal with some not very efficient legacy apps/DBs that you cannot totally control. In that case the extra count query may affect the performance of the app quite badly.

You have 2 possible solutions in order to improve the performance.

# Cache the count

Depending on the nature of the app, a possible cheap solution would be caching the count of the collection, and Pagy makes that really simple.

Pagy gets the collection count through its pagy_get_vars method, so you can override it in your controller. Here is an example using the rails cache:

controller
# override the pagy_get_vars method so it will call your cache_count method
def pagy_get_vars(collection, vars)
  vars[:count] ||= cache_count(collection)
  vars[:page]  ||= params[vars[:page_param] || Pagy::DEFAULT[:page_param]]
  vars
end

# add Rails.cache wrapper around the count call
def cache_count(collection)
  cache_key = "pagy-#{collection.model.name}:#{collection.to_sql}"
  Rails.cache.fetch(cache_key, expires_in: 20 * 60) do
    collection.count(:all)
  end
end
model
# reset the cache when the model changes (you may omit the callbacks if your DB is static)
after_create { Rails.cache.delete_matched /^pagy-#{self.class.name}:/ }
after_destroy { Rails.cache.delete_matched /^pagy-#{self.class.name}:/ }

That may work very well with static (or almost static) DBs, where there is not much writing and mostly reading. Less so with more DB writing, and probably not particularly useful with a DB in constant change.

# Avoid the count

When the count caching is not an option, you may want to use the countless extra, which totally avoid the need for a count query, still providing an acceptable subset of the full pagination features.

# Use AJAX

You can trigger ajax render in rails by customizing the link attributes.

See also Using AJAX.

# Maximize Performance

Here are some tips that will help choosing the best way to use Pagy, depending on your requirements and environment.

# Consider the nav_js

If you need the classic pagination bar with links and info, then you have a couple of choices, depending on your environment:

  • Add the oj gem to your gemfile and use any pagy*_nav_js helper (see Javascript). That uses client side rendering and it is faster and lighter than using any pagy*_nav helper (40x faster, 36x lighter and 1,410x more efficient than Kaminari). Notice: the oj gem is not a requirement but helps the performance when it is available.

# Consider the combo navs

If you don't have strict requirements but still need to give the user total feedback and control on the page to display, then consider the pagy*_combo_nav_js helpers. They are faster and lighter, and even more when the oj gem is available. That gives you the best performance with nav info and UI (48x faster, 48x lighter and 2,270x more efficient than Kaminari) also saving real estate.

# Consider the countless extra

If your requirements allow to use the countless extra (minimal or automatic UI) you can save one query per page, and drastically boost the efficiency eliminating the nav info and almost all the UI. Take a look at the examples in the support extra.

# Consider the Arel extra and/or the fast_page gem

You can improve the performance for grouped collections with the arel extra, and queries on big data with fast_page.

# Ignore Brakeman UnescapedOutputs false positives warnings

Pagy output html safe HTML, however, being an agnostic pagination gem it does not use the specific html_safe rails helper on its output. That is noted by the Brakeman gem, that will raise a warning.

You can avoid the warning adding it to the brakeman.ignore file. More details here and here.

# Handle Pagy::OverflowError exceptions

Pass an overflowing :page number and Pagy will raise a Pagy::OverflowError exception.

This often happens because users/clients paginate over the end of the record set or records go deleted and a user went to a stale page.

You can handle the exception by using the overflow extra which provides easy and ready to use solutions for a few common cases, or you can rescue the exception manually and do whatever fits better.

Here are a few options for manually handling the error in apps:

  • Do nothing and let the page render a 500
  • Rescue and render a 404
  • Rescue and redirect to the last known page (Notice: the overflow extra provides the same behavior without redirecting)
controller
rescue_from Pagy::OverflowError, with: :redirect_to_last_page

private

def redirect_to_last_page(exception)
  redirect_to url_for(page: exception.pagy.last), notice: "Page ##{params[:page]} is overflowing. Showing page #{exception.pagy.last} instead."
end

# Test with Pagy

  • Pagy has 100% test coverage.
  • You only need to test pagy if you have overridden methods.

If you need to test pagination, remember:

  • Pagy::DEFAULT should be set by your initializer and be frozen. You can test that your code cannot change it.
  • You can override defaults - i.e. any pagy variable can be passed to a pagy constructor. For example:
@pagy, @books = pagy(Book.all, items: 10) # the items default has been overridden

# Using your pagination templates

If you really need to use your own templates, you absolutely can. Here is a static example that doesn't use any other helper nor dictionary file for the sake of simplicity, however feel free to add your dynamic variables and use any helper and translation as you need:

<%#
  The link variable is set to a proc that returns the link tag (complete with rel and aria-current)
  Usage: link.call( page_number [, text [, extra_attributes_string ]])
-%>
<% link = pagy_link_proc(pagy) -%>
<nav class="pagy_nav pagination" aria-label="Pages">
  <%# Previous page link %>
  <% if pagy.prev -%>
    <span class="page prev">
      <%== link.call(pagy.prev, '&lt;', 'aria-label="Previous"') %>
    </span>
  <% else -%>
    <span class="page prev disabled">
      <a role="link" aria-disabled="true" aria-label="Previous">&lt;</a>
    </span>
  <% end -%>
  <%# Page links (series example: [1, :gap, 7, 8, "9", 10, 11, :gap, 36]) %>
  <% pagy.series.each do |item| -%>
    <% if item.is_a?(Integer) -%>
      <span class="page">
        <%== link.call(item) %>
      </span>
    <% elsif item.is_a?(String) -%>
      <span class="page active">
        <a role="link" aria-disabled="true" aria-current="page"><%== item %></a>
      </span>
    <% elsif item == :gap -%>
      <span class="page gap">&hellip;</span>
    <% end -%>
  <% end -%>
  <%# Next page link %>
  <% if pagy.next -%>
    <span class="page next">
      <%== link.call(pagy.next, '&gt;', 'aria-label="Next"') %>
    </span>
  <% else -%>
    <span class="page next disabled">
      <a role="link" aria-disabled="true" aria-label="Next">&gt;</a>
    </span>
  <% end -%>
</nav>

You can use it as usual: just remember to pass the :pagy local set to the @pagy object:

<%== render file: 'nav.html.erb', locals: {pagy: @pagy} %>

You may want to read also the Pagy::Frontend API documentation for complete control over your templates.