Masaki Komagata

@reckyy あまり影響が大きすぎないように2~3か所ぐらいで使われてるやつがいいかな～と思います。

@reckyy > とおっしゃっていますが、この2つの条件を満たすパーシャルであれば、view_componentの導入効果がそれほど高くなさそうでも問題ないということでしょうか。 はい。 最終的には効果の高い場所に導入したいですが、まずはview_componentが導入できそうかを見たいので、影響範囲がそれほど大きくないところで試したいです。 その結果によってはやっぱり導入をやめるということもあるので。 そう考える理由としては、基本的にrailsプロジェクトに追加のライブラリ（gemでもnpmでも）を追加するとrailsやその他のライブラリのバージョンアップにかかるメンテナンスが大変になります。 最初にアプリを作っているときは便利なライブラリをたくさん導入したほうが楽ですが、メンテナンス時には標準以外のライブラリはなるべく使わないほうが楽です。（railsのメジャーバージョンアップ時などは特に） 最初の開発よりメンテナンスのほうが圧倒的に時間がかかるので、ライブラリは相当に効果があって、そのあともメンテし続けられる覚悟がないと導入できないものだからです。

@reckyy formはデータを変更するセンシティブなところなので避けたいです。 https://github.com/fjordllc/bootcamp/blob/main/app/views/works/_work.html.slim こちらはいかがでしょうか。

@masyuko0222 gitの操作はコマンドだけではなく、今自分がどのブランチにいるのかが影響するので上記だけだとわからない感じです。 また、githubのコメント（コミットコメントではなく）の位置関係などは気にしなくていいと思います。

@masyuko0222 gitを使っているので好きな状態にいつでも戻せるはずですので、普通はリファクタリングにブランチは切らないです。そのままでお願いします。

@masyuko0222 かしこまりました。現状のコードでレビューさせていただきます。

@masyuko0222 レビューでOKもらってからまたリファクタリングするとなるとレビューの意味がなくなっちゃうのでリファクタリングするのであればそのままやっちゃってください。 （一般的にはリファクタリング可能なことがわかっているのにやらずにPRを提出することはない感じです。）

@masyuko0222 PKはなぜuuidなんでしょうか？

@masyuko0222 > 今回は未ログインユーザーも退会申請ができるため 未ログインの場合はcurrent_userがないと思いますが、user_idはどうなりますか？

参考: https://github.com/fjordllc/bootcamp/pull/7640#issuecomment-2129784344 @machida すみません、こちらってレアなユースケースに対して大量のコードと複雑なデータを生んでしまうように思いました。 まずは、ログインしているアドバイザーが退会するための「アドバイザー用の退会フォーム」を用意して、パスワードを忘れた方には「パスワード忘れ」を使っていただいて、それでも、問題があったり、何度もお問い合わせがきて普段の業務が大変となってからこういったものを作るのが良いのではないかと思いました。