Rails 5.1の変更点まとめ #JavaScript

はじめに

去る2017年2月23日、Rails 5.1.0.beta1が公開されました。

Rails 5.1.0.beta1: Loving JavaScript, System Tests, Encrypted Secrets, and more - Riding Rails

Rails 5.1ではマイナーバージョンアップと言えど、かなり大きな変更点が多数入っているようです。
そこで上記公式ブログの内容を僕なりにまとめてみます。

おことわり

この記事は公式ブログやpull requestの内容を読んで、筆者が個人的にまとめたものです。
実際に動かして試したりはしていないので、おかしな内容や誤解している内容が含まれている可能性もあります。

もし、「これは明らかにおかしい！」という内容を見つけた場合は、コメントや編集リクエストで優しく指摘してやってください。

サンプルコードについて

この記事はとりあえず、Rails公式ブログの内容をなぞる形で執筆しています。
各機能の具体的なサンプルコード等については、「参考」として載せてあるリンク先のコードやpull requestの内容を確認してください。

2017.3.22追記：リリースノート(英語)もあわせて読むと効果的です

Rails 5.1のリリースノートが以下の公式ページにまとめられています。

Ruby on Rails 5.1 Release Notes — Ruby on Rails Guides

サンプルコードも交えて新機能が紹介されているので、本記事とあわせて読むとさらに効果的です。

JavaScriptのサポート改善

JavaScriptのサポートで大きく変わったのは以下の3点です。

1. yarnとNPMでJavaScriptの依存関係を管理できるようになった

bin/yarnコマンドでJSの依存ライブラリを追加できるとのこと。
これにより、Reactのようなライブラリをyarn + NPMで簡単に追加できるようになる。

2. オプションとしてWebpackを使ってJavaScriptをコンパイルすることも可能

新規プロジェクト作成時に、--webpackオプションを付けると、Webpacker gem用の設定が自動的に行われ、Webpackを簡単に使えるようになる。
Webpackは従来のアセットパイプラインと完全な互換性がある。
アセットパイプラインとWebpackを共存させることも可能。
アセットパイプラインやWebpackの管理はYarnがデフォルトで行う。

3. jQueryがデフォルトの依存ライブラリから外された

rails-ujsを純粋なJavaScriptで書き直したことにより、jQueryの導入が必須ではなくなった。
これにより、jQueryを使い続けることも、使わないようにすることも自由に選択できるようになる。

2017.2.27追記：実際に使ってみたので解説記事を書きました

Rails 5.1を使ってVue.jsのサンプルアプリケーションを作ってみました。
想像以上に簡単に作成できたので、こちらもぜひご覧ください。

【動画付き】Rails 5.1で作るVue.jsアプリケーション～Herokuデプロイからシステムテストまで～ - Qiita

参考

システムテスト

CapybaraとChromeを利用するSystemTestCaseがRailsに組み込まれた。
これにより、面倒な設定無しにJavaScriptに依存する画面のテストが書けるようになる。
テストが失敗したときはスクリーンショットが保存される。
データベースのクリーンアップ（テスト実行時のトランザクション管理）についても、フレームワークが面倒を見てくれる。
ただし、システムテストは遅いというトレードオフがあるので、上手に使い分ける必要がある。

2017.2.26追記：システムテストを試してみました

実際にSystemTestCaseを使ってみたので、以下にその内容をまとめてあります。

Rails 5.1のSystemTestCaseを試してみた - Qiita

参考

暗号化されたsecrets

bin/rails secrets:setupというコマンドを使うことで、暗号化されたsecretsを作成することができる。
secretsは暗号化されるので、GitHubのリポジトリにpushすることも可能。

暗号化されたファイルを作成する際にマスターキーが発行されるので、この値だけをリポジトリ外で管理する。

本番環境ではRAILS_MASTER_KEYという環境変数にマスターキーの値を格納することで、暗号化されたsecretsを復号化できる。

これにより、本番環境用のパスワードやAPIキーをGitHubにpushすることを避けたり、それらの値を環境変数に保存したりする従来のプラクティスが不要になる。

参考

パラメータ化されたmailer

コントローラと同じようにmailerにパラメータを渡し、アクションを実行する前に処理できるようになった。
これにより、デフォルトのto/from/reply_toといった値をDRYに書くことが可能になる。

この仕組みは完全に後方互換性を保っているので、パラメータ化による効果が高そうなmailerから優先的に適用していくことが可能。

参考

Directed routesとResolved routes

Directed routesを使うと、渡されたパラメータに対して自由にルーティングを設定できる。

Resolved routesを使うと、モデルに応じたポリモーフィックなURL生成のルールを再定義できる。
これにより、link_to @commentという記述で、message_path(@comment.parent, anchor: "comment_#{@comment.id}")と同等な結果が得られるように設定できる。

シンプルなAPIであれば従来のルーティングで十分だが、場合によってはパラメータに応じて複雑なロジックでルーティングを決定しなければならないケースがある。
これまではヘルパーメソッドの作成や、その他の煩わしい実装が必要だったが、Directed routesやResolved routesを使うと、そのルールをroutes.rb内で定義できるようになる。