29
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Railsの”shallow(浅い)”ルーティングを理解する

Last updated at Posted at 2021-01-09

何をしたか

Railsの課題を実施しています。DB構造はこんな感じで、userに紐づくpostと、それぞれに紐づくcommentsがあります。

Image from Gyazo

その中で、post-comment間のルーティングについてshallowを使いましょうとの指示があったのですが、実は、shallowは悪手だと聞いていたこともあって、自分では使っていませんでした。

とはいえ**「悪手なのでやめましょう」**ではなんの発展もないので、shallowがどんなルーティングを生んでいるのか、および

  • shallowを肯定する人の意見
  • そうではない人の意見

も比べて、今後自分の担当するプロジェクトにおいて使う・使わないを検討する材料にしたいと思います。

なお、実行環境は下記の通りです。

  • Rails 5.2.3
  • Ruby 2.6.0

shallowはどんなルーティングを生んでいるか

shallowは、ネストしたルーティングにおいて、下層にあるテーブルのIDが一意なら、その上にあるテーブルのIDは不要という発想に基づいています。

具体的には、以下のようにネストしたルーティングを記載すると...

config/routes.rb
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

editshowupdatedestroyの4アクションで、URIパターンがスッキリし、ヘルパーメソッドも短くなっていることがわかります。

画像だともう少しスッキリしている感がわかりやすいかなと思ったので、rails routesで出力した結果も載せておきます。

▼Shallowあり
Image from Gyazo

▼Shallowなし
Image from Gyazo

だいぶスッキリしていますね:relaxed:

shallow肯定派の主張

shallow(浅い)ルーティングを肯定する人の主張はまさにここで、

  • ルーティングがスッキリする
  • URLがカッコ悪くない
  • ヘルパーもスッキリしてコードの見通しが良くなる

ということだと思います。

Qiitaでよく閲覧されている記事には、この辺がありそうです。

resources を nest するときは shallow を使うと幸せになれる

では、悪手だという人の主張はどこにあるのでしょうか。

shallow否定派の主張

1) RESTfulでない

私がよく聞く理由の一つがまずこれで、例えば、

  • newとdestroyのリダイレクト先の設定に困った(どのPOSTにリダイレクトすれば良いのだ問題)
  • newとeditのフォームでURLの指定が異なる(newには親のIDが含まれるけど、editには含まれない)

などがあります。

2) 他の実装者の混乱を招く

これは、弊社だけかなあと思いつつ...。URIパターンが普段よく見るルーティング異なるため、

  • ネストしているのかURLからわかりづらくなる
  • ヘルパーメソッドの確認がいちいち大変

などで地味にコストがかかっております...:sweat_smile:

3) その他の主張

そのほか、私は実際に見たことはないですが

  • SQLインジェクションを招きやすい
  • 渡すParamsが増える(今回も実はcreateとupdateで渡すparamsを変えなければいけなかった)

などのデメリットもある様です。
主な主張はこちらにまとまっているかなあと思いました。

Railsのroutesのshallowは安易に使わないで欲しい

考察:今回の実装画面

最後に、今回実装することになっている画面をよく見ると、コメントは非同期通信で画面のすぐ上に投稿する(リダイレクトが発生しない)作りだったり、

Image from Gyazo

EditとNewフォームは分かれていたりするので(画面は実装中なので、実装出来次第画像は差し替えます)、上記のshallowの欠点は影響しない範囲ではないかと思いました^^

結論:自分はshallow使うか

いろいろ考えたのですが、自分は積極的にはshallowは使わないかなと思いました。最大の理由は**「チームに混乱を招くから」**で、スムーズに開発を進めるという意味では、shallowは使わない方が幸せになれそうです。

一方で、お客さんに納品するアプリなどで、お客さんから注文があった場合には、使用場面を考慮した上でshallowを使うのもありかなとは思います。

普段のコミュニケーションでリンクをシェアするときなどに、やはりスッキリしたURLの方がかっこいいですものね:innocent:

以上、shallowに関する考察と感想でした。

29
15
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
29
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?