Rails 総復習1ヶ月チャレンジ 7日目(Railsチュートリアル編)

はい！7日目です！
今日は昨日通っているスクールの講師の方にチュートリアルの復習としてテストを出題されたのでその回答を書いていきます！（ボロボロでした。。。）

7日目(Railsチュートリアル　1〜13章復習テスト 前編)

helperのユースケースとdecoratorとの違いは？

helperはviewで使うメソッドをまとめるものという認識で、decoratorとの違いは分かりませんでした。なので調べてみました！

• helperはモデルから独立し直接関係していない描画ロジックを実装
• Decoratorは特定のモデルに関連した描画ロジックを実装

helperの特徴としてどこからでもその定義を取得できてしまう特徴があり、名前の混雑が起きてしまう可能性があります。

それを踏まえると使い分けとしては
helperは複数のモデルに跨って使いたい場合 decoratorは1つのモデルにのみ関連したロジックを記載したい場合

といった感じでしょうか。

ちなみにdecoratorをわざわざ使わなくてもmodelにロジック書いちゃえばいいんじゃない？という疑問は発生するかと思います。私も発生しました。これは下記を参考にするとスッキリしました。

【Rails入門】ViewとModelの間にDecorator（Draper）を置く | 侍エンジニアブログ

Modelは「データ管理だけ」を担当し、Viewは「情報表示だけ」を担当する、という役割分担です。 そして新しく登場するDecoratorには、「（プログラムで管理しやすい）データ」を「（ユーザーが理解しやすい）情報」に変換する役割を持たせます。

違うなどあればご指摘いただけると幸いです！

参考：
Rails Viewの表示のためにDecoratorを用意してHelperとModelを助ける - Qiita

バリデーションって何で設定しないといけないの？

今までマイグレーションファイルで制約設定したらmodelでもバリデーション設定する！という意識でしたが、これも調べます。

参考にしたのは下記です。
Active Record バリデーション - Railsガイド

これを参考に回答すると

正しいデータをデータベースに保存する為。modelレベルでのバリデーションはデータベースに依存せず、テストやメンテナンスもしやすい。バリデーションをかけないでDB側の制約だけで対応していたとして、万が一DB側の制約の掛け忘れなどがあった場合に不正なデータが登録されてしまうなどが発生することもありうる為、モデル側でまず同様のバリデーションを設定し、不正なデータがDBに入らないように防ぐ必要がある。

このような形でしょうか。

form_withで使っているemail_fieldとpassword_fieldってなに？text_fieldじゃダメなの？

これも何となく使っていました。。

• email_field フォームに入力された値に@がないとメールアドレスと認識されずエラーとなる
• passoword_field フォームに入力された値が自動的にマスク（※みたいなやつ)される

参考： 【Rails】 form_forの使い方をマスターしよう！ | Pikawaka - ピカ1わかりやすいプログラミング用語サイト
password_field | Railsドキュメント

今日はここまで！次回は残りの復習部分やっていきます！