何をしたか
Railsの課題を実施しています。DB構造はこんな感じで、userに紐づくpostと、それぞれに紐づくcommentsがあります。
その中で、post-comment間のルーティングについてshallowを使いましょうとの指示があったのですが、実は、shallowは悪手だと聞いていたこともあって、自分では使っていませんでした。
とはいえ「悪手なのでやめましょう」ではなんの発展もないので、shallowがどんなルーティングを生んでいるのか、および
-
shallowを肯定する人の意見 - そうではない人の意見
も比べて、今後自分の担当するプロジェクトにおいて使う・使わないを検討する材料にしたいと思います。
なお、実行環境は下記の通りです。
Rails 5.2.3Ruby 2.6.0
shallowはどんなルーティングを生んでいるか
shallowは、ネストしたルーティングにおいて、下層にあるテーブルのIDが一意なら、その上にあるテーブルのIDは不要という発想に基づいています。
具体的には、以下のようにネストしたルーティングを記載すると...
resources :posts, shallow: true do
resources :comments
end
以下のようなcommentsのルーティングが生成されます。
| ヘルパー | リクエスト | URI | アクション |
|---|---|---|---|
| post_comments | GET | /posts/:post_id/comments | index |
| post_comments | POST | /posts/:post_id/comments | create |
| new_post_comments | GET | /posts/:post_id/comments/new | new |
| edit_comment | GET | /comments/:id/edit | edit |
| comment | GET | /comments/:id | show |
| comment | PATCH | /comments/:id | update |
| comment | DELETE | /comments/:id | destroy |
ちなみに、shallowがない時はこんな感じです。
| ヘルパー | リクエスト | URI | アクション |
|---|---|---|---|
| post_comments | GET | /posts/:post_id/comments | index |
| post_comments | POST | /posts/:post_id/comments | create |
| new_post_comments | GET | /posts/:post_id/comments/new | new |
| edit_post_comment | GET | /posts/:post_id/comments/:id/edit | edit |
| post_comment | GET | /posts/:post_id/comments/:id | show |
| post_comment | PATCH | /posts/:post_id/comments/:id | update |
| post_comment | DELETE | /posts/:post_id/comments/:id | destroy |
edit、show、update、destroyの４アクションで、URIパターンがスッキリし、ヘルパーメソッドも短くなっていることがわかります。
画像だともう少しスッキリしている感がわかりやすいかなと思ったので、rails routesで出力した結果も載せておきます。
▼Shallowあり
▼Shallowなし
だいぶスッキリしていますね
shallow肯定派の主張
shallow（浅い）ルーティングを肯定する人の主張はまさにここで、
- ルーティングがスッキリする
- URLがカッコ悪くない
- ヘルパーもスッキリしてコードの見通しが良くなる
ということだと思います。
Qiitaでよく閲覧されている記事には、この辺がありそうです。
resources を nest するときは shallow を使うと幸せになれる
では、悪手だという人の主張はどこにあるのでしょうか。
shallow否定派の主張
1) RESTfulでない
私がよく聞く理由の一つがまずこれで、例えば、
- newとdestroyのリダイレクト先の設定に困った（どのPOSTにリダイレクトすれば良いのだ問題）
- newとeditのフォームでURLの指定が異なる（newには親のIDが含まれるけど、editには含まれない）
などがあります。
2) 他の実装者の混乱を招く
これは、弊社だけかなあと思いつつ...。URIパターンが普段よく見るルーティング異なるため、
- ネストしているのかURLからわかりづらくなる
- ヘルパーメソッドの確認がいちいち大変
などで地味にコストがかかっております...
3) その他の主張
そのほか、私は実際に見たことはないですが
- SQLインジェクションを招きやすい
- 渡すParamsが増える（今回も実はcreateとupdateで渡すparamsを変えなければいけなかった）
などのデメリットもある様です。
主な主張はこちらにまとまっているかなあと思いました。
Railsのroutesのshallowは安易に使わないで欲しい
考察：今回の実装画面
最後に、今回実装することになっている画面をよく見ると、コメントは非同期通信で画面のすぐ上に投稿する（リダイレクトが発生しない）作りだったり、
EditとNewフォームは分かれていたりするので（画面は実装中なので、実装出来次第画像は差し替えます）、上記のshallowの欠点は影響しない範囲ではないかと思いました＾＾
結論：自分はshallow使うか
いろいろ考えたのですが、自分は積極的にはshallowは使わないかなと思いました。最大の理由は「チームに混乱を招くから」で、スムーズに開発を進めるという意味では、shallowは使わない方が幸せになれそうです。
一方で、お客さんに納品するアプリなどで、お客さんから注文があった場合には、使用場面を考慮した上でshallowを使うのもありかなとは思います。
普段のコミュニケーションでリンクをシェアするときなどに、やはりスッキリしたURLの方がかっこいいですものね
以上、shallowに関する考察と感想でした。