Help us understand the problem. What is going on with this article?

Kaminari 1.0.0 でやってくる 5 つの大きな変更

More than 3 years have passed since last update.

Rubygems には現在 Kaminari 1.0.0.rc1 が出ているが、近いうちに 1.0.0 をリリースする予定である。大きな変更点がいくつもあるので、利用者のためにこれらの重要な変更点をまとめておこうと思う。

古い Ruby と Rails のバージョンのサポート打ち切り

Kaminari 1.0.0 では、以下のバージョンのサポートを打ち切ることにした。

  • Ruby 1.9.3
  • JRuby 1.7
  • Rails 4.0 とそれ以前のすべてのバージョン

これらのバージョンを使っている人は、まず kaminari 0.17.0 で Ruby や Rails をアップグレードしてから kaminari 1.0.0 へアップグレードしてほしい。

Gem を細分化

Kaminari 1.0.0 で最も大きな変更はなんといっても、今まですべてのコードを一つの gem で管理していたものを、kaminari-activerecord といったように、個別の gem に細分化した点である。最も一般的な利用例である Rails 上では、これまで通り Gemfile に、

gem 'kaminari'

と記述されていれば今まで通り利用できるので、何も変更する必要はない。ただし、MongoidSinatra と一緒に利用したい場合はそれぞれの gem を追加する必要がある。たとえば、Rails と Mongoid を利用したい場合は、

gem 'kaminari-core'
gem 'kaminari-mongoid'
gem 'kaminari-actionview'

となり、Sinatra と ActiveRecord の場合は、

gem 'kaminari-core'
gem 'kaminari-activerecord'
gem 'kaminari-sinatra'

となる(kaminari-core は他の gem から参照されているので省略可)。現在利用可能な gem は github.com/kaminari で見ることができる。もし kaminari のインターフェースに対応した特定の DB のための gem をメンテナンスしているという人がいたら、連絡を頂ければ kaminari オーガニゼーション配下にリポジトリを移すことができるので、興味があれば連絡をしてほしい。

rails g kaminari:views-e haml/slim オプションを非推奨へ変更

これまで、erb に加えて hamlslim のテンプレートをリポジトリで管理し、-e オプションによって指定できるようになっていたが、erb を haml や slim に変換するのはコマンド一発で可能なのに対し、haml や slim のテンプレートをリポジトリ内で管理するのは非常にコストが高かった。Haml はともかく、メンテナーで slim の文法を理解している人がいないため、 kaminari_themes に pull reuqest が送られてきても何が正しいのか判断ができなかった。また、現状の管理方法では、haml や slim の文法が変わった場合に複数バージョンに合わせたテンプレートの管理方法が無い(あるいは非常に面倒になる)。さらに、可能性は低いものの、もし新しいテンプレートエンジンが実装されたら、すべての theme に対して新しいテンプレートファイルを追加しなければならないのだろうか。
このような事情から、-e haml/slim オプションは deprecate して、将来的には haml や slim を使いたい場合は手元で変更してもらうという方法をとることにした。つまり、erb テンプレートを single source of truth のようなものとして扱おうということである。これに伴い、新しい theme の追加は erb のみを追加してもらうことにして、既存の haml/slim テンプレートにはバグ修正のみを受け付けるという方針をとることにした。

Pagination without count を試験的に導入

Kaminari は pagination に必要なリンクを表示するために count クエリを発行するが、DB のデータが巨大だと count を計算するために(RDBMS によっては)長い時間がかかってしまい、それがボトルネックになるという問題があった。これを回避するために、1.0.0 からは #without_count というメソッドが追加された。これは、ページに表示する要素の数 +1 の分のレコードを DB から取得し、その追加分の要素が存在するかどうかで次のページの有無を判断している。このような仕組みのため、総ページ数を表示することは原理的に不可能になるが、#link_to_next_page メソッドと #link_to_previous_page メソッドは count クエリ無しで利用することができる。

@users = User.page(params[:page]).without_count

1.0.0 では試験的な導入であるため、明示的に #without_count を呼ぶ必要があるが、大きな問題が報告されなければ将来的にこれをデフォルトとする計画もある。Count クエリに悩まされている人はぜひ試してほしい。

params_on_first_page オプションの追加

これまで #paginate が表示する最初のページへのリンクは、すべての params を無視していた。しかしながら、たとえばフィルターのような機能が params を使って実装されていた場合に、最初のページに戻るとすべてのフィルターがなくなってしまうという問題があった。これを解決するために、params_on_first_page という config が追加された。

# This file is typically located at `config/initializers/kaminari_config.rb`
Kaminari.configure do |config|
  config.params_on_first_page = true
end

Feedback をお待ちしております

これ以外にもたくさんの変更があるが、これ以外の変更は CHANGELOG で確認してほしい。もし使っていて何か変な挙動がある、バグのようなものを見つけたという場合には、ぜひ GitHub issues まで連絡下さい。

yuki24
Ruby committer, Ruby on Rails contributor, Kaminari maintainer, creator of the did_you_mean gem
http://www.yukinishijima.net
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした