ユーザー管理機能 編集機能実装編

どうもバンバンです。
今回はRailsでユーザー管理機能を実装する方法を復習を兼ねて 残していこうと思います。
ユーザ管理機能は全部書くと長くなるので何編かに分けて投稿していきます。
 
はじめに
前回 DBへの保存とページの作成を終えたので、今回はユーザー情報編集機能を実装していきます。
いつものように用語集→手順で進めていきます。
 
用語集
7つのアクション
アクション名
内容
index
一覧表示
show
詳細表示
new
生成
create
保存
edit
編集
update
更新
destroy
削除
基本プログラミング用語はそこまで丸暗記する必要ないと思っていますが、これはよく出てくるので覚えておいたほうが効率が良いです。
 
resourcesメソッド
7つのアクションへのルーティングを自動生成するメソッド
ルーティングを生成する=config/routes.rb に記載
引数に:シンボルと指定するとそのパスに対応するルーティングが生成される。
ex) resources :users ←/usesのパスに対応するルーティング
即ちcontrollers/users_controller.rbで7つのアクションを定義できる。
 
onlyオプション
resourcesにオプションとして加えると 指定したアクションのみのルーティングを自動生成する。
ex) resources :users これだけだと7つ全て生成
そこで resources:users, only: :editとすると
controllers/users_controller.rbでeditのアクションのみ定義できる
絞る理由:不要なアクションを設定しておくことで余分なエラーが発生する恐れがあるから。
編集と更新の機能だけあれば良いならonly: [:edit , :update]
 
redirect_toメソッド
redirect_to パスと記載 パスはrails routesで確認
新たなリクエストを送信された時と同じ動きになる。
よってインスタンス変数が上書きされた状態でビュー画面へたどり着く
ex)controllers/users_controller.rb
def update
if current_user.update(user_params)
redirect_to root_path
現在のユーザーのユーザー情報更新が正しくできた場合新しい更新データを持ったままルーティング→コントローラー→ビューの流れでたどり着く
最後にビューで表示されるユーザー情報は更新された情報
 
renderメソッド
render :アクションと記載
新たにリクエストされることがない。
よってインスタンス変数に変化がないままビュー画面へたどりつく(というよる単純に表示される)
else
 
render :edit
 
end
値が正しくなければ(空欄など)情報は上書きされずedit.html.erbへ戻る
 
手順
今回はユーザー情報の編集機能を実装するので
ルーティング→コントローラ作成と設定→ページ遷移も実装
 
ルーティング
ユーザー編集に必要なルーティングはeditとupdate
usersコントローラでeditとupdateが利用できるように
resources :users,only:[:edit, :update]と記載してルーティング設定
 
コントローラー生成
rails g controller コントローラー名
今回のコントローラー名はusers
 
コントローラー設定
editとupdateをルーティングしているのでその2つのアクションを定義する
 
edit・・編集画面を表示させるだけでよいので
def edit
end
と記載し、views/edit.html.erbの表示をリクエストする
*views/edit.html.erbは既に作成済みとして話を続けます
 
update・・編集内容が更新されるように設定
def update
 
current_user.update(user_params)
↑ストロングパラメーターで許可されているnameとemailのみ
更新 current_user=現在のユーザー
end
 
 
private
 
 
def user_params
 
params.require(:user).permit(:name, :email)
↑nameとemailの編集のみ許可するストロングパラメーター
 
end
 
end
前編でも述べましたがストロングパラメーターがなぜ必要なのかは後日ブログに書こうと思っています。
 
ページ遷移の機能実装
更新が成功したときはチャット画面へ移動
失敗したときはeditページに戻ってくるように設定
redirect toメソッドとrenderメソッドを利用する
def update
 
if current_user.update(user_params)
 
redirect_to root_path
↑更新が成功した場合root_path(チャット画面)へ
else
 
render :edit
↑失敗した場合editページを表示する(情報は更新されていない)
 
end
 
end
 
private
 
def user_params
params.require(:user).permit(:name, :email)
end
 
今回はここまで 次回はログアウト機能の実装編になります。

ユーザ管理機能 カラム&ビュー編

どうもバンバンです。
今回はRailsでユーザー管理機能を実装する方法を復習を兼ねて 残していこうと思います。
ユーザ管理機能は全部書くと長くなるので何編かに分けて投稿していきます。
 
はじめに
前回 導入とファイルの配置が完了したので
DBへの保存方法とログイン状態によって表示させるページを切り替える方法をご紹介します。
 
用語集
before_action
コントローラで定義されたアクションが実行される前に
共通の処理を行うことができる
class コントローラ名 < ApplicationController
 
before_action :処理させたいメソッド名

authenticate_user!メソッド

ログイン状態によって表示するページを切り替えるメソッド
 
処理が呼ばれた段階でユーザーがログインしていなければ
ユーザーをログイン画面に遷移させる機能を追加
controller/application_controller.rbにて
before_actionで呼び出す。
 
app/controllers/application_controller.rb
 
class ApplicationController < ActionController::Base
 
before_action :authenticate_user!
 
end
 
ストロングパラメーター
受け付けたパラメーターが、本当に安全なデータかどうかを検証した上で取得するための仕組み。
この仕組を使うことで意図しないデータの登録・更新を防いでくれる。
何故必要なのかをここで書き始めると横道に逸れまくるので、今回は記載しないです。また後日ブログにします。
 
configure_permitted_parametersメソッド
主にbefore_actionにて使用する
deviseでストロングパラメーターを使用する際に必要
configure_permitted_parametersのメソッド名で使用されることが多い
 
devise_parameter_sanitizer.permit(:deviseの処理名,keys:[:許可するキー])
処理に対して 指定された名前と同じキーを持つパラメーターの取得を許可するストロングパラメーター
ex)devise_parameter_sanitizer.permit(:sign_up, keys:[:name])
↑サインアップの際にnameカラムの取得を許可
 
処理名
役割
:sign_in
サインイン(ログイン)の処理を行うとき
:sign_up
サインアップ(新規登録)の処理を行うとき
:account_update
アカウント情報更新の処理を行うとき
deviseでストロングパラメーターと言えば、上記2つを覚えておく
 
手順
 
app/controllers/application_controller.rbに記載
deviseのコントローラーは編集できないので
上記コントローラーに記載する必要がある
class ApplicationController < ActionController::Base
 
before_action :authenticate_user!
処理が呼ばれた段階でユーザーがログインしていなければユーザーをログイン画面に遷移させる
end
2 before_action:configure_permitted_parameters,if: :devise_controller?と記載
↑全てのアクションが実行される前にdevise_controllerから呼び出された場合configure_permitted_parametersメソッドが呼ばれる
private
 
def configure_permitted_parameters
 
devise_parameter_sanitizer.permit(:sign_up, keys: [:name])
↑ストロングパラメーターを設定する
 
end

ユーザー管理機能実装 導入編

どうもバンバンです。
今回はRailsでユーザー管理機能を実装する方法を復習を兼ねて 残していこうと思います。
ユーザ管理機能は全部書くと長くなるので何編かに分けて投稿していきます。
 
はじめに
今回はゼロの状態から導入するまでの流れと用語を投稿します。
 
用語集
 
devise
 
ユーザ管理機能を実装するためのGem
【インストール方法)
1コードエディタのGemfileの最後の行にgem 'devise'と記載する
2コマンドを実行してGemをインストール
bundle install
3ローカルサーバー再起動
 
rails g devise:installコマンド
deviseの設定関連に使用するファイルを自動で生成するコマンド
 
# deviseの設定ファイルを作成
% rails g devise:install
 
 
rails g deviseコマンド
ユーザー機能の対象を指定することで
モデル・マイグレーションの生成・ルーティングの設定を
まとめて処理してくれる。
# deviseコマンドでUserモデルを作成
% rails g devise user
上記コマンドのようにdevise+model名で実行
 
rails g devise:viewコマンド
コマンドを実行することでapp/viewsの配下にdeviseに用意されたviewファイルを配置してくれる。
配置することでカスタマイズが可能になる
% rails g devise:views
 
導入方法
今回は特に用語集と重複する部分があります。
1コードエディタのGemfileの最後の行にgem 'devise'と記載する
2コマンドを実行してGemをインストール
bundle install
3ローカルサーバー再起動
4ターミナルでrails g devise:installを実行
5ユーザ機能の対象をrails g devise model名で指定する
6app/views配下にrails g devise:viewコマンドでdeviseのviewファイルを配置
 
次回はユーザ管理機能 カラム&ビュー編を投稿します。

部分テンプレートについて

どうもバンバンです。
今回は部分テンプレートについて復習する機会が
あったので備忘録として残していきます。
 
単語集
 
部分テンプレート
ビューファイルで繰り返し使用するコードを
切り出して再利用する仕組み
ex)汚くてごめんなさい

f:id:banban5775:20201119010244j:plain

部分テンプレート例
この同じ記述をするページが多くなればなるほど
コードは増えるし面倒くさいので、別の場所に記述
しておいて必要になれば呼び出してしまおう!
ってときに使用する仕組み
 
_〇〇.html.erbファイル
上記の別の場所のこと
ここに記載しておき、必要なときに呼び出す
 
renderメソッド
部分テンプレートを呼び出す際に利用するメソッド
<% render ~>
これだけではどの部分テンプレートを呼び出したいのか不明なので
オプションで指定していきます。
 
partialオプション
renderメソッドで使用できるオプション
<% render partial: "〇〇">
〇〇の部分テンプレート全体を指定する。これで_〇〇.html.erbを呼び出すことができる。
ex)
views/users/_user.html.erb
この部分テンプレートを呼び出したい場合
 
views/users/index.html.erbへ呼び出す記述は
<% render partial: "user">になります。
しかし同じusers傘下で無い場合は記述が少し異なります。
 
views/tweets/new.html.erbへ呼び出したい場合
<% render partial: users/user">となり
どのディレクトリの部分テンプレートなのかを明記する必要が出てくる
 
localsオプション
部分テンプレート内で変数を使えるようになるオプション
 
<div class="contents row">
<% @tweets.each do |tweet| %>
 
<%= render partial: "tweet", locals: { tweet: tweet } %>
tweet左にtweetm右を代入
 
<% end %>
</div>

Rails TYPE種類と外部キー

どうもバンバンです。
今日は新しいカリキュラムを学習する中で、外部キーと外部キー制約について復習する機会があったので備忘録として残していこうと
思います。
 
Type
railsのカラムで使用する文字列の種類
 
Typeの種類
string...文字列が255字まで
text...文字列が256字以上
reference...t.reference :〇〇と記述すると、〇〇ではなく〇〇_idを作成してくれる 但し外部キー制約がつかない
 
外部キー
異なるテーブルのレコードと関係性を持つ場合に必要な
カラム。他のテーブルのレコードを識別するために使う
 
外部キー制約
外部キーの対応するレコードが必ず存在しなくてはいけないという制約。
ex) t.reference :user, foreign_key: true
の場合 userカラムがあるレコードが存在しなくてはならないということ。先にレコードを作成していないと書き込みができないなどの問題が発生する。
 
身近なものを図にするとわかりやすい印象です。

中間テーブルとアソシエーション

どうもバンバンです。
今回も備忘録として学習した内容を残しています。
 
中間テーブル
2つのテーブルの中間にあるテーブルのこと。
多対多の関係にある2つのテーブルの間に挟まって、2つの
組み合わせパターンだけをレコードとして保存する。

https://tech-master.s3.amazonaws.com/uploads/curriculums//03bf658972e178f7d395d54537911b20.png

中間テーブルの役割確認
タグを保存するテーブル
tagテーブル
写真を保存するテーブル
photosテーブル
どの写真にどのタグが登録されているかを保存するテーブル
photos_tagsテーブル

一つのタグは複数の写真を持っている
一枚の写真は複数のタグを持っている
以上のことからtagテーブルとphotosテーブルは多対多といえる
 

https://tech-master.s3.amazonaws.com/uploads/curriculums//9be4a7c41153ba7f21720be872dd4717.png

中間テーブルにはどの写真にどのタグが登録されているか
という情報が記録されている。ひとつのレコードには「photo_id × tag_id」の組み合わせが記録され、すべての写真とタグの組み合わせの数だけ、レコードが蓄積されていきます。
 
導入の仕方(アソシエーションの組み方)
・has_manyメソッドのthroughオプションを使用
・belongs_toメソッドを中間テーブルのモデルに記載

https://tech-master.s3.amazonaws.com/uploads/curriculums//ebab2cae982f28479fb134d3bf5553f9.png

上の図より
photosテーブルは
photos_tagsに1対多
tagsに多対多であることから
 
models/photo.rbに
has_many :photos_tags 1対多
has_many :tags, through: :photos_tags photos_tagを経由して多対多の関係で表すことができる。
 
同じ用にtagsテーブルでは
has_many :photos_tags 1対多
has_many :photos, through: :photos_tags photos_tagを経由して多対多の関係で表すことができる。
 
photos_tagsからみると1対1の関係になるため
belongs_to :photo 1対1
belongs_to :tag 1対1
というふうに記載すれば良い
 
復習
has_manyメソッド
1対多の関係があることを示すメソッド

https://tech-master.s3.amazonaws.com/uploads/curriculums//2c650eac8ca22ee53f29eba5b62c57a0.png

上の図でいうなら
一人のユーザーは複数のツイートを持っている関係と言える
つまり1対多。
この場合の記述は
models/user.rbにhas_many :tweetsと記載する
ユーザーから見るとツイートは複数あるのでtweetsと複数形で
表現する
 
belongs_toメソッド
1対1の関係があることを示すメソッド

https://tech-master.s3.amazonaws.com/uploads/curriculums//799f15841d495a56c2adbcecaac343ac.png

上の図でいうなら
一つのツイートは一人のユーザーに所属している関係と言える
つまり1対1。
models/twwet.rbにbelongs_to :userと記載する。
ツイートから見るとユーザーは一人なので単数形

新規登録の際に名前をうち込めないエラーについて

今日もエラー似関しての備忘録を残していきます。

今回遭遇したエラーは、ツイートアプリを作成している

際に、ユーザー登録機能を実装し、テストした際に発生。

 

発生したエラー

nickname

mail

password

をそれぞれ入力した際にnicknameに入力できず、入力フォーム上部に

何も記入していない状態では保存できません。といった内容の

エラー文が記載されている。

 

推測

入力→保存の間で

1 値がない

2 単純に記載ミス

3 ユーザ管理機能の不具合

 

復習

ユーザー管理機能実装の簡単な流れ

1 Gem deviceのインストール

2 devise設定ファイル作成

3 モデル作成

4 ボタンの表示を変える

5 コントローラーにリダイレクトを設定

6 テーブルにカラムを追加

7 ビュー作成

8ストロングパラメーターの設定

9 application_controller.rbの編集

 

推測2

他の項目は入力できていることから7までは

問題ないと推測

application_controller.rbが編集されていることから

8もクリア

以上のことから9の編集内容に問題があるのでは

と仮定し、原因を探す

 

原因

application_controller.rbの

def configure_permitted_parameters

    devise_parameter_sanitizer.permit(:sign_up, keys: [:name])

  end

この文のkeys:{:name}←カラム名が:nameになっています。

 

解決方法

name → nickname に修正

エラーは解消されました。

 

今回は長々と復習の意味合いも含め、全体的に見直しましたが

他の値が入力できている時点で、

入力→保存の動作不良=application_controller.rbを確認といった

認識でいいと思います。

 

また似たようなエラーに遭遇した場合は追記していきます。