コードの共通化を意識する ④ ビュー編

自分がエンジニアバイトをしているところでは週1回Rails勉強会をしています。今回はそのやったところのまとめを残しておきます。
参考書：現場で使える Ruby on Rails 5速習実践ガイド

Viewの共通化の方法

Viewでは共通化する部分がロジックとテンプレートの二箇所あります。

ロジックの部分

カスタムヘルパー(app/helpers)に共通処理をまとめる
Decoratorパターンモデル固有の表示ロジックを分離する

テンプレートの部分

パーシャルテンプレート(render)で画面の一部を共通化する
レイアウトで画面の大部分を共通化する(ヘッダーとかフッターとか)

パーシャルテンプレートの共通化

パーシャルはどこのディレクトリに入っているものでも、複数のテンプレートに自由に埋め込むことができる部分的なテンプレートです。パーシャルはどこのディレクトリのものでも呼び出すことは出来ますが、呼び出しているディレクトリと一緒の場所に置いておくのがわかりやすく、管理しやすいです。例えば、ユーザーの画面を扱うUserディレクトリがあり、そこの登録ページで登録フォームをパーシャル化するなら、Userディレクトリ内に__forml.html.slimのような形で作成します。
複数のディレクトリ間で共通化するときは共通用のディレクトリに作成し、そこにパーシャルを配置するとどこから参照しているのかわかりやすく、意図せぬ変更の影響を受けにくくなります。ここで大事なのがパーシャルを共通化するときはHTMLの構造が来ているから共通化するのではなく、目的の類似性に着目しましょう。構造だけで共通化すると後々変更があった時、結局共通化を解除する必要が出てきてしまうからです。

レイアウトで画面の大枠を共通化

個別ファイルごとの共通化ではなく、ヘッダーやフッター、サイドバーのように全てのテンプレートに共通させたい大枠なテンプレートに関しては、layoutディレクトリのようなものを作成し、そこに配置します。application.html.slimファイルに埋め込むことで大枠を共通化し、アクション毎で変化させる際は「yield」メソッドを呼び出した位置に埋め込まれます。

カスタムヘルパーに共通処理をかく

ヘルパーを利用することで複数のビューで共通処理をまとめることができます。ただヘルパーはデフォルトで全てのコントローラで表示されるビューの中から利用できてしまう為、ヘルパーのメソッド名をアプリケーション全体で意味がとれるようにしたおく必要があります。

カスタムヘルパーは小さくつくる

カスタムヘルパーを実装する時は一つ、一つのヘルパーを小さな処理に留め、名前もその目的にあったものにするのがいいでしょう。複雑な処理にしたい時はヘルパーを組み合わせることで実装する必要があります。
ヘルパーはどこからでも呼び出せてしまうグローバルな存在のため、一個の処理に対し複数のビューの条件分岐をさせることで、どのビューでも使えるようにしてしまう「何でも屋」のようになりがちです。そうなると余計な処理まで加えることとなり、コードが難解なものになってしまいます。なのでヘルパーを作る時は小さく作るのが重要になってきます。

特定のモデルに依存する処理をヘルパーに含めない

case record
when Comment
  record.locked?
when Post
  !record.created_at.today?
else
  false end

ヘルパー内に特定のモデルのデータやふるまいに依存する処理が入り込むことは以下の問題があります。

本来モデルにあるべきコードが分散している状態になる。record.locked?や!record.created_at.today?なんかは本来モデルに置き、呼び出すだけにするのがいい
CommentやPostのように特定のモデル専用のコードがビューに生まれてしまい、ビジネルロジックが混在してしまう