バリデーション復習してみた

超初心者なのでまだそんなこと言ってるの？など色々思われることがあると思いますが、個人の向上のためつらつらと書いていきたいと思います。
※「それちゃうで！」などあればどんどんご指摘ください。

・苦手なバリデーションは所詮基礎ができていない。

①そもそもバリデーションとは？
端的にいうと不正なデータをデータベースに記録する前にチェック（検証）してふるいにかけてくれるすごいやつ。
もちろん、不正なデータだった場合はそれをお知らせする手立てもあります。

②バリデーションを書く場所は？
状況：雑魚Twitterアプリを作成
バリデーションの記載はmodelに記述します。

validatesメソッド を設定する

※今回は存在性の検証と文字数制限（5０文字）の検証
class Post < ApplicationRecord
  validates :content, presence: true, length: { maximum: 50 }
end

今回は存在性の検証と文字数制限（5０文字）の検証

③実際にバリデーションできているのか確認
ここまで準備できたらひとまずOK。
これで本当にバリデーションが実行されるのかを確認してみる。
方法は簡単、rails c でコンソールを起動させて挙動を確認する。

※空文字、つまりは存在しないcontentカラムをnewしてみると結果はfalseになります。
$ rails c
> post = Post.new(content: "")
> post.save
=> false

上では「Post.new(content: "")」空文字、つまりは存在しないcontentカラムをnewしてみるとpost.saveの実行結果はfalseになります。
ということは、validatesのpresence: trueが機能しているってこと！

※文字数制限も同じ要領で確認できます。

存在性の検証ができていることはここまででわかったと。
では、それをどうやって操作している人に知らせるのか。
ここで活躍するのが『エラーメッセージ』です。

ひとまず、エラーメッセージが実際に発行されているのか否か確認していく。

ここでもrails cでコンソール起動させてみましょう。

先程の不正なデータ（空のcontent）を生成。

$ rails c
> post = Post.new(content: "")

次からがミソです。
post.errors.full_messagesを出力してみましょう。

> post.errors.full_messages
=> []

現状はまだデータの生成のみなので特に検証にかかっていない状況です。
そのため、errors.full_messagesをしても何もメッセージが生成されていません。
もっといえば、生成はされているけれど空の配列が生成されている状況です。
では、saveしてみましょう。　...当然ですが失敗します。

> post.save
=> false ← 検証で空のデータは受付ないよ ということでfalse

さて、検証に引っかかった状況がこれで整いました。
もう一度errors.full_messagesしてみると…。

> post.errors.full_messages
=> ["Content can't be blank"]

空だった配列にエラーメッセージが見事に生成されています！

こんな感じでバリデーションからエラーメッセージを生成する流れとなります。
これに絡めてrenderについても書けたらと思いましたが、力尽きたのでまた今度まとめます。

ポートフォリオ様に雑魚システム作ってもやっぱりアウトプットしようとなるとうまく説明できませんね。
テキスト見ながら振り返りつつこの記事も作成していますが、時間かかりますけど改めて勉強になりました。

ただ、こういうエラーメッセージはサーバーサイドバリデーションになるのであまりよろしくないとな。
JavaScriptなどで即時フィードバックができるようにするべきという事です。
参考記事
https://ferret-plus.com/7724
https://popinsight.jp/blog/?p=4113

よし、さらに成長しちゃいますよ！