64,65日は土日なので休日です。最終課題に関しては最低限はもう終わっているので自分のやりたいことだけやってる感じ。この頃は既に面接に行っていたので正直、TECH::EXPERTはどうでもよくなっていた。
rails
slice!
指定した文字列を削除する。
自信を変更するが、返り値は削除した文字列。削除後の文字列ではない。
ぼっち演算子
&はsafe navigation operator、 lonely operatorなどと呼ばれる演算子。
オブジェクトがnilの場合にもエラーにならずにメソッドを当てることができ、nilを返す。
一方でオブジェクトがnilでない場合に、使用できないメソッド当てるとundefined errorを返す。
よく使うのは下記のような未ログイン時にエラーとなるようなメソッドでも、nilが返るためにエラーにならない。
@name = current_user&.name類似のメソッドにtryやtry!がある。
try!はぼっち演算子と同等だが、実行速度がやや遅い。
tryは未定義のメソッドの場合もエラーは返さず、nilを返す。
最も重要な点は、tryはrailsのメソッドであるが、&はrubyのメソッドである。
dependent: :destroy
has_many :books ,dependent: :destroy
createとcreate!
saveやupdateも同様。保存に失敗した場合やエラー時に!だと例外を投げる。
!付きで成功した場合には、作成したインスタンスを返す。
逆に！抜きだと成功時にtrue、失敗時にfalseを返す。
save! エラー時は全て例外を投げる。
save モデル層のエラー（invalidやcallbackでのエラー）はboolean、
その他のエラーは例外（DB側やインフラ側でのエラー）
トランザクション
一連の処理。データの整合性を保つため、処理を一塊にしたもの。
トランザクションを張っている場合、処理が成功した場合にのみ一連のデータを保存する。
逆に失敗した場合には処理の途中まで進んでいたとしても一連の処理の全てをロールバックする。
トランザクションを張っている処理の場合は、saveやcreate、updateはsave!で記述する。
そうしない場合、予期せぬ例外が発生した場合に、途中までの処理が保存されてしまい、データの整合性が保てなくなる。
validation
DBでの制約とvalidationの役割がかぶることについて。
役割が同じだからと言ってvalidationの記載を省略すると、DB側で保存処理に失敗した場合に例外が投げられる。こうなると連続したデータの保存時に、失敗があっても次のデータを保存するというような処理を継続できず、トランザクションのロールバックが起こるか、途中までの保存で中断するかの2択になる。
逆にvalidationをしっかり記載しておけばsaveメソッド（!なし）であれば例外ではなくbooleanが返るために処理を継続できる。
html
html5からvalidationが掛けられる。
patternを指定したり、required属性を指定することで必須入力にしたりできる。
<input type="email" name="email" pattern="[\w\d_-]+@[\w\d_-]+\.[\w\d._-]+" required />
基礎
CSRF
cross-site request forgeries
forgeryとは偽造の意。
常時ログイン等で自分がログインしているサービスに対し、外部からリクエストを送られる。
railsでは5.2以前では以下の記述がapplication.html.erbに記載されており、フォーム等のpostリクエストを行う要素に対してauthenticity tokenが発行されている。
このトークンと照合することにより内部からのリクエストかどうかを判断し、外部からのリクエストを遮断している。
protect_from_forgery with: :exceptionrails 5.2以降では記載が省略されるが、callback時に差し込まれるよう変更されている。
https://railsguides.jp/upgrading_ruby_on_rails.html#protect-from-forgeryは今後デフォルトでprepend-falseに設定される
ajaxについてもapplicaiton.htmlにcsrfメタタグが含まれており、これで判断しているため、ajaxも認証できる。
コメント