bootcamp
bootcamp copied to clipboard
fjordllc
view_componentを導入する
https://github.com/ViewComponent/view_component を導入し、使うのにふさわしいと思う場所を一箇所view_component化する。
@komagata お疲れ様です。こちらのIssueの認識についてお伺いしたいです。
使うのにふさわしいと思う場所を一箇所view_component化する。
こちらの「使うのにふさわしいと思う場所」の認識を確認させていただきたいです。 自分は以下のようにあまり行数がない1〜2つのファイルを移行するのが妥当かなと考えました。ですが、ポイントが3なので、ある程度の(3~4?)ファイルの移行を想定されているのかもと考え、お伺いした次第です。
お尋ねしたいこと
どのぐらいのボリューム（ファイル数、ファイル内のコードのボリューム）のファイルの移行を想定されているか。
使うのに相応しい場所の探し方
置き換えるべきファイル
- ヘルパーメソッドを多用している
- 複雑なロジックを含む
- ビューファイル内部でモデルからデータを取得している
- テストがしにくい（ちょっとこの条件の具体的なイメージはついてないですが。。）
上記4つが最も混在しているパーシャル。
ただ、以下の条件を考慮する必要がある。
- 影響範囲があまり大きくない
- ファイル内部で大量にrenderしていないなど。してもせいぜい2つ。
- 内部で使用しているヘルパーメソッドが、移行するファイルのみで使用されていること。
@reckyy 僕が言葉足らずでわかりずらかったですね、すみません。
基本的にview_componentを導入する効果が高いところをやりたいなとおもいます。
- そのview_componentが少なくとも二か所以上から使われる。（一か所からだとあまり使う意味がないので）
- インスタンス変数とviewのセットが他から切り離されている（そのcomponent以外のものをたくさん呼び出していたりせず、切り離しやすいもの）
とりあえず、ここをやろうとおもっているとおしえていただければそちらを見て判断します～。
@komagata とんでもないです！コメントいただきありがとうございます。
現在、
- 2箇所以上でrenderされている
- 独立している
上記2点を満たすパーシャルを探すということですね。承知しました。 目星をつけたら、再度コメントにてお知らせいたします。
@komagata お疲れ様です。ファイルを眺めて自分的に良さそうだと感じたファイルを共有します。 （この後にも出てくれば、追記しますが取り急ぎ。）
-
app/views/application/_errors.html.slimhttps://github.com/fjordllc/bootcamp/blob/033db0ed12ea2354cd2456213f8a3c0716b8ba8e/app/views/application/_errors.slim#L1-L9- 24箇所で使用されている
- 渡すインスタンスが一つである
ことからポイントの作業量的にも妥当かなと感じました。 ご確認をよろしくお願いいたします。
@komagata お疲れ様です。 少し確認なのですが、https://github.com/fjordllc/bootcamp/issues/7521#issuecomment-2003165568 では
基本的にview_componentを導入する効果が高いところをやりたいなとおもいます。 ・そのview_componentが少なくとも二か所以上から使われる。（一か所からだとあまり使う意味がないので） ・インスタンス変数とviewのセットが他から切り離されている（そのcomponent以外のものをたくさん呼び出していたりせず、切り離しやすいもの）
とおっしゃっていますが、この2つの条件を満たすパーシャルであれば、view_componentの導入効果がそれほど高くなさそうでも問題ないということでしょうか。 それとも、この2つの条件を満たしつつ、導入効果が高いファイルを選択すべきでしょうか。
というのも、中々その2つの条件を同時に満たしてはいるが、効果が高そうなファイルがなく、、特に2〜3箇所で使われているファイルは見た感じどのファイルも、そこまで導入効果が高そうではないです。（https://github.com/fjordllc/bootcamp/blob/main/app/views/shared/_not_logged_in_footer.html.slim や、 https://github.com/fjordllc/bootcamp/blob/main/app/views/admin/campaigns/_form.html.slim のように） そのため、質問させていただきました。
ご確認お願いいたします。
@reckyy
とおっしゃっていますが、この2つの条件を満たすパーシャルであれば、view_componentの導入効果がそれほど高くなさそうでも問題ないということでしょうか。
はい。
最終的には効果の高い場所に導入したいですが、まずはview_componentが導入できそうかを見たいので、影響範囲がそれほど大きくないところで試したいです。
その結果によってはやっぱり導入をやめるということもあるので。
そう考える理由としては、基本的にrailsプロジェクトに追加のライブラリ（gemでもnpmでも）を追加するとrailsやその他のライブラリのバージョンアップにかかるメンテナンスが大変になります。
最初にアプリを作っているときは便利なライブラリをたくさん導入したほうが楽ですが、メンテナンス時には標準以外のライブラリはなるべく使わないほうが楽です。（railsのメジャーバージョンアップ時などは特に）
最初の開発よりメンテナンスのほうが圧倒的に時間がかかるので、ライブラリは相当に効果があって、そのあともメンテし続けられる覚悟がないと導入できないものだからです。
@komagata コメントありがとうございます。 ライブラリ導入の段階について、理解できました。ありがとうございます。 不安になったので確認なのですが、「ファイル（パーシャル）一つをコンポーネント化」であって、「ファイルの再利用可能な一部をコンポーネント化」ではない、という認識で大丈夫でしょうか。
条件を満たしつつ、影響範囲が小さいファイルをピックアップしました。 このファイルをコンポーネント化するのはどうでしょう。 https://github.com/fjordllc/bootcamp/blob/main/app/views/books/_form.html.slim
/views/books/edit.html.erb と /views/books/new.html.erb の2箇所でrenderされています。
@reckyy formはデータを変更するセンシティブなところなので避けたいです。
https://github.com/fjordllc/bootcamp/blob/main/app/views/works/_work.html.slim
こちらはいかがでしょうか。
@komagata
formはデータを変更するセンシティブなところなので避けたいです。
条件ばかりに目が入ってました。申し訳ございません。
こちらはいかがでしょうか。
条件も満たしており、良いと思います！ 早速取り掛かります。
最終ご提案いただく形になり、お手数おかけし申し訳ないです。 🙇