1. ViewComponentとは

再利用可能で、テストがしやすく、カプセル化されたビューコンポーネントを作るためのRailsのgem。
Reactから影響を受けた、Presenter(ViewのためのUIのビジネスロジックを書く)パターンの進化版。

ざっくり言うと、フロントでは当たり前のように使われているコンポーネントの概念を、ViewComponentを使ってRailsのビューにも取り入れて、同じようなビューのコードをコンポーネント化させちゃおうというもの。

ここで「それなら既にRailsにはパーシャルがあるんだからそれ使えばいいんじゃないの？」という話になるが、どうやらViewComponentを使った方が良い理由があるらしい。その理由を以下で確認する。

2. ViewComponentを導入すべき5つの理由

Railsでは、ビューのテンプレートがコントローラ、モデル、ヘルパー等に分散し、本来の責務が薄れてしまうということがよく起こる。

ViewComponentは同一のビューロジックを1つのクラスに集約し、シンプルにまとまったオブジェクトを実現する。プロジェクト内に同じようなロジックが散らばるみたいなことを防げる。

ViewComponentでは全てのコンポーネントがユニットテストされることを前提に設計されている。今までのRailsのビューテンプレートでは難しかったビュー自体のユニットテストが可能になるだけでなく、類似のコントローラのユニットテストと比較して、100倍以上速くテストができる。

ViewComponentのユニットテストはCapybara matchersライブラリを活用し、従来はコントローラやブラウザテストに限定されていた複雑なアサーション(あるコードが実行される時に満たされるべき条件を記述して実行時にチェックする仕組み)を可能にする。

従来のRailsのテンプレートは暗示的なインターフェースであったため、読み込み場所によっては上手くレンダリングされずにバグが起こるみたいなことが発生していた。

その点ViewComponentでは標準的なRubyのイニシャライズを用いて、データを明示的に渡してレンダリングさせるため、安全であり、再利用が簡単である。どういうデータが渡されるのか、容易に予測ができる。

平均的にパーシャルよりも10倍高速である。

速さの要因は読み込みのタイミングにある。従来のRailsテンプレートは実行時に読み込まれていたが、ViewComponentのテンプレートは、アプリケーション起動時にプリコンパイルされる。

Railsのテンプレートでは、長いメソッドであったり、深いネストの条件式であったり、標準のRubyのお作法から外れてしまうことがよくある。

ViewComponentは単なるRubyのオブジェクトのため、コードの品質基準を守ることが比較的に容易である。

ViewComonentはビューのロジックを一元化できる他に、ユニットテストのしやすさやパフォーマンス・品質の向上等の面から、パーシャルよりも優れていると言える。

よって特に下記のような箇所がViewテンプレート内に見つかった場合は、ViewComponentの導入を検討してみても良いかもしれない。

次回は実際にサンプルアプリにViewComponentを導入し、RSpecでテストを書いて、上記のメリット等を確認してみる。