sugulogの日記

Railsのdevise!ユーザー登録機能を実装しよう!!〜後編〜

f:id:sugulog:20201016203028p:plain
こんにちは、すぐるです!

sugulogをお読みいただきありがとうございます!!

このブログは、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準に書いています。

少しでもお役に立てれば幸いです。

 

今回は、Railsのdeviseということで

  • ユーザー登録機能の後編

について簡単に解説します!!

その為このブログを読むことで、deviseについて理解できるのはもちろん、ユーザー登録機能の実装についての理解も深まります。

是非最後までご愛読ください。

 

今回は、

  •  rails g devise:viewsコマンド

  • rails g migrationコマンド

  • devise_parameter_sanitizerメソッド

の順で解説していきます。

また、前回のブログの内容を引き継いで記述しています。

そのため、前回のブログを必ず1度読んでからお読みください。

sugulog.hatenadiary.jp

では早速、みていきましょう!!

rails g devise:viewsコマンド

deviseに予め用意されているビューファイルをコピーし、app/viewsの配下に配置してくれるコマンド。

このコマンドを実行することにより、deviseのビューを自分でカスタマイズすることが可能になります。

 では実際に、rails g devise:viewsを実行しましょう。

実行した結果、app/views/devise/registrations/new.html.erb(新規登録)app/views/devise/sessions/new.html.erb(ログイン)などのビューが配置されました。

この後実際に、少しカスタマイズしてみましょう!

rails g migrationコマンド

マイグレーションを生成するコマンド。

今まではrails g modelコマンドを実行するとモデルと一緒にマイグレーションも生成されていました。

しかし、すでに作成されたテーブルの内容を変更する際などにはコマンドを実行し、新たにマイグレーションを生成する必要があります。

コマンドを実行する際は、以下を入力し実行します。

rails g migration Addカラム名To追加先テーブル名 追加するカラム名:型です。

この結果、テーブルにカラムを追加する際に必要なコードが記述された状態でマイグレーションが生成されます。

今回はusersテーブルにNicknameを追加したいため、

rails g migration AddNicknameToUsers nickname:stringを実行しました。

そのため以下のように、テーブルにカラムを追加する際に必要なコードが記述された状態のマイグレーションが生成されました。

f:id:sugulog:20201017140354p:plain

rails db:migrateを実行し、Sequel Proなどで追加されているか確認しましょう!

 ではカラムを追加したのでdeviseのビューを少しカスタマイズしてみましょう!!

今回は新規登録のビューに、以下のように記述しました。

f:id:sugulog:20201017145040p:plain

追加で記述した箇所は、6行目〜9行目のみです。

その他はもともと記述されています。

その結果、以下のように表示されています。

f:id:sugulog:20201017145439p:plain

Nicknameが追加されていますね!!

・devise_parameter_sanitizerメソッド

deviseで予め設定されているストロングパラメーターに対し、パラメーターを追加することがでるメソッド。

新しくカラムを追加したのでdeviseのストロングパラメーターにnicknameを追加し、情報を受け取れるようにしたいところです。

しかしdeviseの処理を行うコントローラーはGem内に記述されているため編集することができません。

そのため使用するのがdevise_parameter_sanitizerメソッドです。

記述する際は、

devise_parameter_sanitizer.permit(deviseの処理名, keys: [:許可するキー])です。

またdeviseの処理名には、以下のような値を使用できます。

f:id:sugulog:20201017155425j:plain
では実際に記述していきましょう!

f:id:sugulog:20201017152950p:plain

まず注目してもらいたいのが、記述しているファイルです。

deviseのコントローラーファイルに記述することができないので、app/controllers/application_controller.rbに記述しています。

このファイルは全てのコントローラーでの共通の処理を作ることができるファイルです。

そのためここに記述することで、deviseのコントローラーにも反映させることができます!

次に注目してもらいたいのが2行目です。

before_actionを使いメソッドを定義しています。

またif: :devise_controller?という記述は、もしdeviseに関するコントローラーの処理であれば実行するという制限をかけています。

ifオプションは値にメソッド名を指定することで、その戻り値がtureの時のみ処理を実行させるオプションです。

今回は値として、devise_controller?というdeviseのヘルパーメソッドを指定しています。

このifはif文のifではなく、オプションとしてのifなのでしっかり押さえましょう!

そして実行されるメソッドは、4行目〜7行目に記述しています。

private以下に記述することにより、app/controllers/application_controller.rb以外では実行されないようにしています。

またpermitでは新規登録時の処理なのでsign_upを指定し、keyとしてnickname(カラム名)を指定しています。

この結果、新規登録時のnicknameの情報も受け取ることができ保存されるようになりました。

最後に実際に1度保存されるか確認しておきましょう!!

 

以上、今回のブログでした。

deviseについて理解でき、ユーザー登録機能の実装についての理解も深まりましたか??

前回のブログと合わせ、deviseの技術を自分のものにしましょう(≧∀≦)/

 

最後に!!

今後も、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準にブログを書いていきます。

少しでも気になった方はお試しでもいいので1度、読者登録お願いします!

またTwitterでもプログラミングに関することを中心に情報を発信してます。

宜しければそちらのフォローもお願いします。

最後までご愛読いただきありがとうございました!!

 

 

Railsのdevise!ユーザー登録機能を実装しよう!!〜前編〜

f:id:sugulog:20201014150458p:plain
こんにちは、すぐるです!

sugulogをお読みいただきありがとうございます!!

このブログは、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準に書いています。

少しでもお役に立てれば幸いです。

 

今回は、Railsのdeviseということで

  • ユーザー登録機能の前編

について簡単に解説します!!

その為このブログを読むことで、deviseについて理解できるのはもちろん、ユーザー登録機能の実装についての理解も深まります。

是非最後までご愛読ください。

 

今回は、

  • deviseの導入

  • user_signed_in?メソッド

  • redirect_toメソッド

の順で解説していきます。

また、前回のブログの内容を引き継いで記述しています。

そのため、前回のブログを必ず1度読んでからお読みください。

sugulog.hatenadiary.jp

では早速、みていきましょう!!

・deviseの導入

deviseとは、ユーザー管理機能を簡単に実装するためのGemのことです。

今回は、このdeviseを使いユーザー管理機能を実装していきます。

では始めにdeviseをアプリケーションに導入するため、Gemfileにgem 'devise'を記述し、bundle installしましょう。

deviseはdevise専用のコマンドで設定ファイルを作成する必要があります。

そのためまずは、rails g devise:installコマンドを実行しましょう。

rails g devise:installは、deviseの設定関連に使用するファイルを自動で生成するコマンドです。

次に、rails g deviseコマンドを実行しましょう。

rails g deviseコマンドは、rails g devise モデル名とすることでモデルとマイグレーションの生成やルーティングなどの設定をまとめて処理します。

今回は、rails g devise userで実行しました。

f:id:sugulog:20201016173351p:plain

devise_forというdeviseのメソッドを使い、ルーティングが自動生成されているのも確認できますね!
因みにdevise_forメソッドとは、ユーザー機能に必要な複数のルーティングを1度に生成してくれるメソッドです。

では最後に、rails db:migrateを行いテーブルを作成しておきましょう。

これでdeivseの導入が完了です!!

・user_signed_in?メソッド

deviseを導入することで使用できるようになるメソッド。ログインしているかどうかの判定を行い、ログインしていればtureを返しログアウト状態であればfalseを返す。

このメソッドを使用することにより、ログインしている時としていない時に合わせてアプリケーションの見た目や動きを変えることができます!

そのため今回はヘッダーで使用し、以下のように記述しました。

f:id:sugulog:20201016181408p:plain

17行目~27行目に注目してください。

if文を使い場合分けしています。

if user_signed_in?とすることでログインしている状態、つまりtureならelseまでの処理が実行されます。

そしてログインしていない状態、つまりfalseならelse以下の処理が実行されます。

処理内容としてはlink_toを使い、ログアウトボタンや投稿するボタン、ログインボタン、新規登録ボタンを作成しています。

その結果ログインしている時にはヘッダーに、ログアウトボタンと投稿するボタンが表示され、ログアウトしている時はヘッダーにログインボタンと新規登録ボタンが表示されるようになります。

f:id:sugulog:20201016184301g:plain

またlink_toを記述する際ですが、deviseを導入したことによりログインやログアウト、新規登録などのルーティングも自動生成されています。

そのためrails routesを行いパスを調べ、link_toのURLに記述しましょう!!

また注意点があり、ログアウトする際はHTTPメソッドとしてdelete(method: :delete)を指定してあげる必要があります。

・redirect_toメソッド

Railsでリダイレクト処理(本来受け取ったパスとは別のパスへ転送する機能)を行う際に使用するメソッド。redirect_to action: :リダイレクト先となるアクション名で実行できる。

コントローラー等で処理が終わった後に対応するビューファイルを参照せずに、別ページに遷移したりなんかができます。 

今回はredirect_toメソッドを使用し、以下のように記述しました。

f:id:sugulog:20201016195651p:plain

 まず注目してもらいたいのが、4行目です。

before_actionを使いコントローラーが実行される前のメソッドを定義しています。

そしてそのメソッドは、44行目〜48行目に記述しています。

まず、unlessというのはifとは逆でfalseの時に処理が実行されます。

そのためunless user_signed_in?と記述することによりfalseの状態、つまりログアウトしている状態の時に実行される処理を記述することができます。

その中でindexにリダイレクトする処理が記述されています。

この結果、ログアウト状態から新規投稿画面へ直接アクセス(URLを入力)されたとしても、indexアクション(投稿一覧ページ)にリダイレクトされるようになりました。

また4行目でexceptとしてshowを指定しているのは、ログアウト状態で詳細ページにアクセスされて、詳細ページを表示しても問題がないからです。

またindexも指定していますがこれは、ログアウト状態でindexにアクセスされた際指定しないと無限ループが続くので、そのループを防ぐためです。

では最後にURLを直接入力した際、リダイレクトされるかだけ実際に確認しておきましょう。

 

以上、今回のブログでした。

deviseについて理解でき、ユーザー登録機能の実装についての理解も深まりましたか??

今回は前編で、次回は後半です。

合わせて読むことでさらに理解が深まりますので、次回も是非お読みください(≧∀≦)/

 

最後に!!

今後も、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準にブログを書いていきます。

少しでも気になった方はお試しでもいいので1度、読者登録お願いします!

またTwitterでもプログラミングに関することを中心に情報を発信してます。

宜しければそちらのフォローもお願いします。

最後までご愛読いただきありがとうございました!!

Rails、showアクション!投稿の詳細を表示しよう!!

f:id:sugulog:20201014032031p:plain
こんにちは、すぐるです!

sugulogをお読みいただきありがとうございます!!

このブログは、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準に書いています。

少しでもお役に立てれば幸いです。

 

今回は、Railsのshowアクションということで

  • 投稿の詳細表示

について簡単に解説します!!

その為このブログを読むことで、showアクションについて理解できるのはもちろん、詳細表示機能の実装についての理解も深まります。

是非最後までご愛読ください。

 

今回は、

  • 詳細表示ページの実装

  • before_actionメソッド

の順で解説していきます。

また、前回のブログの内容を引き継いで記述しています。

そのため、前回のブログを必ず1度読んでからお読みください。 

sugulog.hatenadiary.jp

では早速、みていきましょう!!

詳細表示ページの実装

f:id:sugulog:20200920151157j:plain

 詳細表示にはshowアクションを使用します。

まず始めにルーティングですが、以下のように記述しました。

f:id:sugulog:20201014042457p:plain

showアクションを追加しました...と言いたいところですが、今回でresourcesに含まれる7つのアクション全てを使用することになりました。
そのためonlyオプションで限定する必要がなくなったので、tweets以降の記述を削除しています。

次に投稿一覧ページに詳細ボタンを、以下のように追加しました。

f:id:sugulog:20201014044712p:plain

10行目に注目してください。

 リンク先のURLとしては、Prefixを使用しています。

rails routesで確認しましょう。

また詳細表示する際は削除などと同じく、どのツイートかを区別する必要があります。

そのため引数でtweet.idを渡しています。

では次にコントローラーですが、以下のように記述しました。

f:id:sugulog:20201014045054p:plain

28行目〜30行目に注目してください。

destroyアクションなどと同じくlink_toから送られてきたidをparamsで受け取り、findメソッドで該当するデータを1つ取り出しています。

その際showアクションでは、ビューでインスタンス変数を使用したいため定義しています。

そして詳細表示ページのビューは、以下のように記述しました。

f:id:sugulog:20201014045731p:plain

基本的には一覧表示ページと同じ記述です。

しかし、大きく違う点が1点あります。

その大きく違う1点は、コントローラーでのデータ取得の際にallではなくfindで取得しているため、ビューに表示する際にeachする必要がなく、インスタンス変数.カラム名で表示しているところです。

@tweetには該当するidのデータが代入されるので、詳細ボタンを押されたツイートのデータが表示されるという流れです。

実際に確認してみましょう!

f:id:sugulog:20201014051000g:plain

投稿一覧ページでは投稿されている様々なツイートを見ることができましたが、詳細ページでは詳細ボタンを押されたツイートのみが表示されており、他のツイートが表示されていないことが確認できたと思います!!

・before_actionメソッド

コントローラーで定義されたアクションが実行される前に行う共通の処理を定義するメソッドのこと。before_action :メソッド名で定義する。

before_actionを使用することで、コントローラー 内の記述をまとめることができます。

今回はeditアクションとshowアクションに共通して記述されている、@tweet = Tweet.find(params[:id])をbefore_actionを使いまとめてみました。

f:id:sugulog:20201014141625p:plain

まずは3行目に注目してください。

before_actionを使い、 コントローラーで定義されたアクションが実行される前に行う共通の処理を定義しています。

またその際にonlyオプションを使い、editとshowアクションのみに実行されるよう制限をかけています。

そして今回はコントローラーで定義されたアクションが実行される前に行う共通の処理を、tweet_idというメソッド名で定義しています。

tweet_idは39行目〜41行目で定義しています。

内容はeditとshowアクションで定義されていた、@tweet = Tweet.find(params[:id])です。

private以下に記述することにより、tweetsコントローラー(対象クラス)以外では使用できないように制限をかけています。

この結果、editとshowアクションに記述してあった、@tweet = Tweet.find(params[:id])の記述を削除することができ、before_actionでまとめることができました。

before_actionはコントローラーで定義されたアクションが実行される前に実行されることをしっかり押さえましょう!

因みにafter_actionと記述するとコントローラーで定義されたアクションが実行後に実行される共通の処理を定義することができます。

では最後に、以前と同じ動きでedit、showアクションが動くかだけ確認しましょう!!

 

以上、今回のブログでした。

showアクションについて理解でき、詳細表示機能の実装についての理解も深まりましたか??

今回までのブログを通して、根幹である7つのアクション全てを学習しました。

後はこのアクションをどのように利用していくかです。

例えば、今回のアプリケーションではnewとcreateでツイートを作成しましたが、コメントやチャットなども作成できます。

日々の生活で様々なサービスに触れる中、少しその裏側も想像してみましょう(≧∀≦)/

 

最後に!!

今後も、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準にブログを書いていきます。

少しでも気になった方はお試しでもいいので1度、読者登録お願いします!

またTwitterでもプログラミングに関することを中心に情報を発信してます。

宜しければそちらのフォローもお願いします。

最後までご愛読いただきありがとうございました!!

Rails、editとupdateアクション!投稿を編集しよう!!

f:id:sugulog:20201014023858p:plain
こんにちは、すぐるです!

sugulogをお読みいただきありがとうございます!!

このブログは、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準に書いています。

少しでもお役に立てれば幸いです。

 

今回は、Railsのeditとupdateアクションということで

  • 投稿の編集

について簡単に解説します!!

その為このブログを読むことで、editとupdateアクションについて理解できるのはもちろん、投稿編集機能の実装についても理解が深まります。

是非最後までご愛読ください。

 

今回は、

  • 編集ページの実装

  • 編集完了ページの実装

の順で解説していきます。

また、前回のブログの内容を引き継いで記述しています。

そのため、前回のブログを必ず1度読んでからお読みください。 

sugulog.hatenadiary.jp

 では早速、みていきましょう!!

・編集ページの実装

f:id:sugulog:20200920151157j:plain

編集ページを表示する際はeditアクションを使用します。

では始めにルーティングですが、以下のように記述しました。

f:id:sugulog:20201013221110p:plain

editアクションを追加しました。

次に投稿一覧ページに編集ボタンを、以下のように追加しました。

f:id:sugulog:20201013221850p:plain

10行目に注目してください。

 リンク先のURLとしては、Prefixを使用しています。

rails routesで確認しましょう。

また編集する際は削除する際と同じく、どのツイートかを区別する必要があります。

そのため引数でtweet.idを渡しています。

では次にコントローラーですが、以下のように記述しました。

f:id:sugulog:20201013225323p:plain

19行目〜21行目に注目してください。

destroyアクションと同じくlink_toから送られてきたidをparamsで受け取り、findメソッドで該当するデータを1つ取り出しています。

その際editアクションはビューでインスタンス変数を使用したいため、定義していることにだけ気をつけましょう!!

そして編集ページのビューは、以下のように記述しました。

f:id:sugulog:20201013233706p:plain

新規投稿時と同じく、入力した情報をフォームで送る必要があります。

そのため新規投稿時と同じフォームを編集ページにも持ってきました。

この際modelの@tweetは新規投稿時と見た目は同じですが、中身は違うのでしっかり理解しておきましょう!

・編集完了ページの実装

データを編集(更新)する際はupdateアクションを使用します。

では始めにルーティングですが、以下のように記述しました。

f:id:sugulog:20201013235901p:plain

updateアクションを追加しました。

次にコントローラーですが、以下のように記述しました。

f:id:sugulog:20201014000336p:plain

23行目〜26行目に注目してください。

destroyアクションなどと同じくどのツイートかを区別する必要があります。

そのためeditのフォームで送られてきたidをparamsで受け取り、findメソッドで該当するデータを1つ取り出しtweetに代入しています。
そして代入されたtweetをupdateメソッドを使い、更新しています。

その際に以前定義したストロングパラメーターを使い、どのデータの値を受け取るかを指定しています!

編集は新規投稿とは違い、idを取得し続ける流れをしっかり押さえましょう!!

では次に投稿完了ページですが、以下のように記述しました。

f:id:sugulog:20201014021032p:plain

では最後に動きを確認しましょう!

f:id:sugulog:20201014024657g:plain


以上、今回のブログでした。

editとupdateアクションについて理解でき、投稿編集機能の実装についても理解が深まりましたか??

編集機能を実装する際は、editアクションからのupdateアクションです。

この流れをしっかりと押さえましょう(≧∀≦)/

 

最後に!!

今後も、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準にブログを書いていきます。

少しでも気になった方はお試しでもいいので1度、読者登録お願いします!

またTwitterでもプログラミングに関することを中心に情報を発信してます。

宜しければそちらのフォローもお願いします。

最後までご愛読いただきありがとうございました!!

HTML、CSSの一問一答!こんな時どうすればいいの??

f:id:sugulog:20201013165750p:plain
こんにちは、すぐるです!

sugulogをお読みいただきありがとうございます!!

このブログは、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準に書いています。

少しでもお役に立てれば幸いです。

 

今回は、こんな時どうすればいいの??ということで

  • HTML、CSSの一問一答

を記述していきます!!

その為このブログを読むことで、HTML、CSSのどうすればいいの?が解決されるのはもちろん、何か困ったときのカンニングペーパーとして参考になること間違いなしです!

また、新しいHTML、CSSの一問一答に出会うたびに追記していきます!!

是非最後までご愛読ください。

 

・HTML、CSSの一問一答

HTML、CSSの一問一答に出会った順に書いてます。

全てのお誘いを断り、心を鬼にしながら学習した思い出順なのでご了承ください。

・HTML上にGoogleマップを埋め込む方法は?? 

Googleマップ上で表示させたい住所を検索する。

左上のメニューバーをクリックし、「地図を共有または埋め込む」をクリックする。

「地図を埋め込む」をクリックする。

「HTMLをコピー」をクリックする。

HTMLで表示したい箇所にペーストすると埋め込める。

・リキッドレイアウトでのページ作りのコツは??

基本的にpxを使用せず、vw、vhで幅、大きさを指定していく。

上限や下限が指定されておりその大きさでビューが崩れない場合や、全体のバランスが悪くならない場合はpxを使用しても問題はない。

フォントサイズはvwで指定すると、ブラウザの大きさによって変化する。

表示領域の横幅の上限や下限を指定する場合は、max-widthやmin-widhtを設定する。

実際にブラウザの幅を変えながらビューは崩れないか、全体のバランスは悪くないかなどを確かめながら実装する。

※自分の感覚で書いているため、ご指摘や他に何かコツがあれば教えてください。

・背景画像をリキッドレイアウト(要素フルサイズ)に対応させる方法は??

background-imageで背景画像を指定する。

background-size: coverで大きさを要素の幅に合わせる。

幅を変えた際に画像のバランスが崩れる際は、background-positionで調整する。

 

以上、今回のブログでした。

何か困ったときのカンニングペーパーとして参考になりそうでしたか??

これからもどんどん知識を蓄えていきますね(≧∀≦)/

 

最後に!!

今後も、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準にブログを書いていきます。

少しでも気になった方はお試しでもいいので1度、読者登録お願いします!

またTwitterでもプログラミングに関することを中心に情報を発信してます。

宜しければそちらのフォローもお願いします。

最後までご愛読いただきありがとうございました!!

Rails、destroyアクション!投稿を削除しよう!!

f:id:sugulog:20201012203903p:plain
こんにちは、すぐるです!

sugulogをお読みいただきありがとうございます!!

このブログは、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準に書いています。

少しでもお役に立てれば幸いです。

 

今回は、Railsのdestroyアクションということで

  • 投稿の削除

について簡単に解説します!!

その為このブログを読むことで、destroyアクションの役割について理解できるのはもちろん、投稿を削除する実装まで理解することができます。

是非最後までご愛読ください。

 

今回は、

  • バリデーション

  • 画像表示

  • Prefix

  • 投稿削除の実装

の順で解説していきます。

また、前回のブログの内容を引き継いで記述しています。

そのため、前回のブログを必ず1度読んでからお読みください。 

sugulog.hatenadiary.jp

投稿削除の実装に入るまでに今までの実装を通し少し触れておきたい概念があるので、そちらから順番に解説していきますね!

では早速、みていきましょう!!

・バリデーション

データ登録の際に一定の制限をかけること。

例えば、空のデータを登録できないようにする、既に登録されている文字列を登録できないようにするなどがあります。

記述の仕方としては対応するモデルのファイルに、validates :カラム名, バリデーションの種類です。

今回は、以下のように記述しました。

f:id:sugulog:20201012151859p:plain

 puresence: tureと記述することで、空ではないか?がtureの時に実行されます。

つまり、空では保存できないバリデーションをかけています。

そのため上記の記述によりtextカラムの値は空で保存できなくなり、空のツイートが登録できなくなりました。

またバリーデーションについては別のブログで詳しく書く予定ですので、そちらで学んでいきましょう!

・画像表示

今回は画像を背景として表示させたいので、以下のように記述しています。

f:id:sugulog:20201012161356p:plain

注目してもらいたいのが、3行目です。

style属性を使い、background-imageプロパティをHTML上に記述することで、urlでtweet.imageを指定しています。

この結果、投稿する際に画像のurlを指定することで画像が表示されるようになりました。

後は自分自身でCSSのファイルを作成し、ビューを整えましょう。

その際、以前解説しましたがapplication.cssがstylesheets直下のCSSファイルを全てのビューに適用させるので、stylesheets直下に対象のコントローラー名のディレクトリを作成し、その中に対象アクションのCSSファイルを作成しましょう!

今回の場合だと、以下のような構造です。

f:id:sugulog:20201012165036p:plain

また、CSSは書けば書くほど技術があがるので試行錯誤しながら、調べながら記述してください!!

f:id:sugulog:20201012163318p:plain

・Prefix

ルーティングのURI Patternに名前をつけて変数化したもの。

URI Patternの代わりに使える変数ってイメージですね!

では実際にrails routesコマンドを実行し、みていきましょう!!

          Prefix    Verb URI Pattern          Controller#Action
root GET /tweets#index
tweets GET /tweets(.:format) tweets#index
      (tweets) POST /tweets(.:format) tweets#create
new_tweet GET /tweets/new(.:format)tweets#new

ここで注目してもらいたいのが、1行目です。

PrefixとURI Patternという記述がありますね。

その下に記述されている文字列がそれぞれの、PrefixとURI Patternです。

今回の場合だと、URI Patternの/tweetsを変数化したものが、Prefixのtweetsです。

そして、URI Patternの/tweets/newを変数化したものが、Prefixのnew_tweetです。

このように、横並びに表示されるPrefixとURI Patternは同じパスを表しています。

今まではURI Patternを使いlink_toのパスなどを指定していましたが、Prefixを使いより簡単に指定することもできるよというお話です!

また記述する際は、Prefexの文字列_pathで記述します。

では実際に、投稿削除の実装を行う中でも確認していきましょう!!

・投稿削除の実装

f:id:sugulog:20200920151157j:plain

データの削除を行うアクションが、destroyアクションです。

そのためこのdestroyアクションを使い、削除機能を実装していきます。

では始めにルーティングですが、以下のように記述しました。

f:id:sugulog:20201012181433p:plain

destroyアクションを追加しています。

次に投稿完了ページに遷移するためのリンクをビューに、以下のように記述しました。

f:id:sugulog:20201012183540p:plain

まずはlink_toで削除完了ページへのリンクを繋いでいます。

ここでPrefixとURI Pattern(コメントアウトしてる方)の両方のパターンを記述してみましたので、見比べてみてください。

因みにrails routesは、以下のように表示されていました。

f:id:sugulog:20201012184431p:plain

そしてここで、押さえておきたいことが2点あります。

1点目が、リンクを繋ぐ際にtweetのidの情報(tweet.id)も一緒に渡しているということです。

このtweetはコントローラーでallで取得し、eachでレコードごとに取り出したブロック変数のことです。

つまり、tweet.textやtweet.nameなどと同じ原理でidを取得しています。

URI Patternではパスの一部(パスの:idの部分)として、Prefixでは引数として渡しています。

このように、idを渡すことによりどのツイートを削除するのかを区別しています。

2点目が、HTTPメソッドとしてDELETEを指定していることです。

削除を行う際この指定をしないと、元からのHTTPメソッドはGETが指定されているため、削除することができません。

そのため、削除を行う際は必ずmethod: :deleteというコードを記述しましょう。

 では次にコントローラーですが、以下のように記述しました。 

f:id:sugulog:20201012190024p:plain

destroyアクションを追加し、その中に処理を記述しています。

15行目はTweet.findでデータを1つ、データーベースから取得しています。

その際に引数でparams[:id]とすることで、先程link_toで取得したツイートのidを取得します。

つまり、link_toから送られてきたパラメーターのidをparamsとして取得し、そのidと一致するデータをfindで1つデータベースから取り出し、tweetに代入しています。

そして16行目でdestroyメソッドを使い、tweetに代入された情報を削除しています。

上記の流れがdestroyアクションです。

必ずこの流れを意識しましょう!!

では次に投稿完了ページのビューですが、以下のように記述しました。

f:id:sugulog:20201012202533p:plain

では最後に動きを確認しましょう!!

f:id:sugulog:20201012203345g:plain

 

以上、今回のブログでした。

destroyアクションの役割について理解でき、投稿を削除する実装まで理解することができましたか??

destroyアクションは今回のブログの流れが非常に重要です!

理解が深まるまでしっかりと押さえましょう(≧∀≦)/

 

最後に!!

今後も、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準にブログを書いていきます。

少しでも気になった方はお試しでもいいので1度、読者登録お願いします!

またTwitterでもプログラミングに関することを中心に情報を発信してます。

宜しければそちらのフォローもお願いします。

最後までご愛読いただきありがとうございました!!

Rials、ストロングパラメーター!ツイートを保存しよう!!

f:id:sugulog:20201005171744p:plain
こんにちは、すぐるです!

sugulogをお読みいただきありがとうございます!!

このブログは、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準に書いています。

少しでもお役に立てれば幸いです。

 

今回は、Railsとストロングパラメーターということで

  • ツイートの保存

について簡単に、より深堀し解説します!!

その為このブログを読むことで、ツイートの保存についての理解がより深まるのはもちろん、ストロングパラメーターなどの概念についても理解できます。

是非最後までご愛読ください。

 

今回は、

  • ルートパスの設定

  • 新規投稿ページの作成

  • ストロングパラメーター

  • プライベートメソッド

の順で解説していきます。

また、前回のブログの内容を引き継いで記述しています。

そのため、前回のブログを必ず1度読んでからお読みください。

sugulog.hatenadiary.jp

では早速、みていきましょう!!

・ルート パスの設定

ツイート保存を実装する前に、ルートパスの設定についてだけ解説します。 

railsアプリを作成した際、localhost:3000という元となるページ(ルート)が作成されました。

ただそのページはrailsアプリが作成できました!とお知らせするページであり、実際のアプリとは全く関係のないページです。

そのため、もしそのページにアクセスがあった際はそのまま表示するのではなく、関係のあるページに遷移したいですね!!

そのためルーティングで、以下のように記述しました。

f:id:sugulog:20201005012115p:plain

root to: "代わりに表示させたいページのURI#アクション名"で遷移先を指定することができます。

今回はトップページである投稿一覧ページを表示させたいため、tweetsのindexを指定しています。

実際にルートにアクセスし、遷移されるか確認しましょう!!

・新規投稿ページの作成

ここは復習になるので、さらら〜といきますね!

まずはルーティングを、以下のように記述しました。

f:id:sugulog:20201005013509p:plain

resourcesでアクションを2つ以上定義する場合は、アクションを[ ]で囲む必要があるので注意です!

次にコントローラーでは、以下のように記述しました。

f:id:sugulog:20201005020933p:plain

今回はフォームを作成する際にインスタンス変数を使用したいため、newメソッドを@tweetに代入してます。

では最後にビューは、以下のように記述しました。

f:id:sugulog:20201005022348p:plainここで注目してもらいたいのがform_withのオプションとして定義している、modelの記述です。

このオプションを使うことでインスタンス変数の中身から判断し、以前はurlで指定していた送信先、HTTPメソッドの定義を自動で行ってくれます!

model: 対象のアクションで定義したインスタンス変数で指定できます。

以前よりかなり楽に設定できますね!!

そしてブラウザでは、以下のように表示されています。

f:id:sugulog:20201005024812p:plain

まだCSSを記述していないのでフォーム自体は整っていませんが、ヘッダーとフッターがしっかり反映されていることが確認できますね!

また投稿するを押すと、しっかりと上記のページに遷移することも確認しておきましょう!!

ではこのまま、投稿完了ページも作成していきます。

ルーティングは、以下のように記述しました。

f:id:sugulog:20201005025707p:plain

新規投稿を保存する際は、createアクションでしたね!

次にコントローラーと言いたいところなんですが、その前に押さえておきたい概念がいくつかあるので、そちらから学んでいきましょう!!

・ストロングパラメーター

指定したキーを持つパラメーターのみを受け取るように制限するもの。

前回のアプリではストロングパラメーターを使用していませんでしたが、ストロングパラメーターを利用することにより取得するパラメーターを制限します。

そして取得したい情報のみを取得し、意図しないデータの更新を防ぎます。

パスワードなどを意図しない形で更新しないためにも、大切な概念になってきます。

そして、ストロングパラメーターの定義にはコントローラーで、requireメソッドpermitメソッドを組み合わせます。

requireメソッドとは、送信されたパラメーターの情報が持つparamsが使用できるメソッドです。

パラメーターからどの情報を取得するかを選択します。

またpermitメソッドも、requireメソッドと同様にparamsが使用できるメソッドです。

取得したいキーを指定でき、指定したキーと値のセットのみを取得します。

記述の仕方としては、params.require(:モデル名).permit(:取得したいキー名)です。

requireメソッドでどのモデルの情報を取得するか指定し、permitメソッドで指定したモデルの中のどのキー(カラム)の値を取得するかを指定できるということです!

・プライベートメソッド

クラス外から呼び出すことのできないメソッド。Rubyではprivateと記述した以下のコードがプライベートメソッドになる。

プライベートメソッドを使用することでclassの外部から呼び出すことを不可能にし、誤って呼び出してしまう等のエラーを事前に防ぐことができます。

また可読性という観点でも、クラスのみで使用する定義をまとめることができます。

少し想像しにくいと思うので先程のストロングパラメーターも含め、crateアクションを定義してみます。

f:id:sugulog:20201005162113p:plain

まずはcreateアクションを定義していますが、引数としてtweet_paramsが渡されています。

このtweet_paramsは、ストロングパラメーターを定義しています。

16行目からみていくと、requireでtweetモデルを指定し、permitでname、image、textキーが指定されています。

この結果createアクションは意図しない情報を含まず、ストロングパラメーターで指定された3つの情報のみを取得し保存します。

ポイントとしては、createアクションの引数としてストロングパラメーターを渡すということです!

またプライベートメソッドですが、private以下の記述が対象となります。

今回の場合だと、tweet_paramsという定義されたストロングパラメーターが対象になります。

この結果tweet_paramsは、tweetsコントローラー以外のクラスでは使用できなくなりました。

これで保存するためのcreateアクションの定義も完了です。

では最後に、投稿完了ページのビューだけ作成しましょう!!

ビューは、以下のように記述しました。

f:id:sugulog:20201005164502p:plain

投稿完了後、投稿一覧ページの戻るリンクだけ忘れず記述しておきましょう!

またブログの始めにルートを投稿一覧ページに遷移したため、上記では遷移先として"/"を指定しています。

投稿完了後、以下のようなページが表示されれば今回のブログは終了です!!

f:id:sugulog:20201005165043p:plain

また新規投稿が、投稿一覧ページにも反映されているか確認しましょう

※現段階では画像の表示記述がないため、画像を投稿しても表示されません。

 

以上、今回のブログでした。

ツイートの保存についての理解がより深まり、ストロングパラメーターなどの概念についても理解できましたか??

ストロングパラメーターは、Railsアプリを作成する上で重要な概念です。

今回のブログでしっかり押さえておきましょう(≧∀≦)/

 

最後に!!

今後も、「 過去の無知な自分に向けてわかりやすく説明するなら?? 」を基準にブログを書いていきます。

少しでも気になった方はお試しでもいいので1度、読者登録お願いします!

またTwitterでもプログラミングに関することを中心に情報を発信してます。

宜しければそちらのフォローもお願いします。

最後までご愛読いただきありがとうございました!!