体重登録
calclateアクション/Before
問題点
一つ目の赤枠と同じコードが実はもう一つ別のアクションでも使われていて、重複している。
二つ目の赤枠では、本来redirect_toでいいのに、renderしておりそこでそのためにインスタンスが生成されるという無駄な処理が行われている。
三つ目の赤枠では、本来はrenderが正しい。
calculateアクション/After
大幅にコード量が減っただけでなく、共通項を一つのコードにしたことで修正が必要なときなどに直す部分が一つで良くなり、保守性が向上した。
共通化したメソッド（Application controller）
身長・BMI登録
Before
今までだと、ビューでもし身長データがあれば、登録された体重からBMIを計算してそれをグラフに反映するというロジックにしており、profileページに行くたびにBMIが計算されグラフに反映される処理が行われるロジックになっていた。
コードの可読性も悪いし、なにより毎回無駄な処理がされるというのは望ましくないため、必要なときのみBMIが登録されるようにした。
具体的にはBMIが登録されるのは、
１ プロフィール編集から身長データを登録した時
２ 身長データがある状態で体重を記録した時
の２パターンで、２はすでに実装されていたので、１を今回は作成した。
UserコントローラUpdateアクション
Application Controllerメソッド
もしユーザが身長データを入力してきたら、既存の体重データからBMIを計算しそれを登録するようにした。
なおupdateなので既存の体重データがなくてもエラーにはならない。
その他
上の修正をしている時に気付いたのだが、今までだと上記のようなコードになっていて、EmailやNameをからで送信すると一番下のrenderでeditページに戻り、そしてそこでは.errors.full_messageが表示されるのだが、もし身長データも空にしていると、renderの前に身長がからの場合にBMIをnilにする記述があるのに、画面ではエラーで更新されていないように見えるが、実はBMIは消えているというよくない仕様になっていた。
それを下記のように、大前提として更新を先に持ってきて、その中でもし身長が空ならBMIをnilにするという風に順番を変えることで、対処した。
※一番下のコメントアウトしている変数の部分を入れると、.errors.full_messageがなくなる。エラーメッセージが前提としているのはデータがないことだけど、ここで生成してrenderしているからエラーとみなされないのだろうか？
LIKES LIKED
Before
After
ユーザのアイコンを表示する部分、いいねの表示・作成・削除の部分と、そしてグラフ表示の部分がLIKES LIKEDで重複していたため、既存のパーシャルで対応できるところはそれで対応した。いいねアイコンの表示及び作成・削除の部分のみ新たにパーシャルを作成した。
ユーザーアイコンのパーシャル
いいねの表示・作成・削除のパーシャル
グラフのパーシャル
【番外編】redirect_toとrender
概要
redirect_toは基本的にデータに更新が会った時に使われる。例えば登録・削除・更新などである。
一方でrenderはデータに更新がない時に使用する。例えばユーザが更新しようとしたけどエラーでデータに変更がなかった時などである。
疑問
だが、redirect_toを使えばわざわざ遷移先のページで必要となる変数などをアクションで生成せずに、その遷移先のページのアクションが生成してくれるので楽だと思う。わざわざrenderでまた変数を用意しなければいけない理由がわからなかった。
例えば下記の画像はグラフへの体重登録が失敗した時のrenderのメソッドであるが、遷移先で必要な変数を多く記述している。
一方もしこれをredirect_toにすれば、下記画像の遷移先ページを表示するeditアクションが変数を用意するので上の一見冗長なコードは不要となる。
なのになぜわざわざrenderを使うのか。
renderを使う理由
答えから書くと、「ユーザが入力したデータを保つため」である。
redirect_toだと遷移先のページのアクションを介すので、すべてが初期値になってしまうが、renderはそこの変数をそのままviewにわたすことができるため、ユーザが入力した値をrender前で変数に入れておけば、遷移先でも表示することができるということである。
よってわざわざ遷移先で必要なデータを用意してまでrenderを使うのは、「よりユーザーフレンドリーな仕様」にするためである。