20200930_アウトプット(devise関連)

アプトプット画像

学んだこと

deviseを用いたユーザーの管理機能について学んだ。

サインアップ/ログイン機能

【１】ログインしていない場合に、ログイン画面に遷移するように実装する。

class ApplicationController < ActionController::Base
  before_action :authenticate_user!
end

authenticate_user!メソッドを使用する。
authenticate(読：オセンティケイトゥ　意：認証する)
ビフォーアクションに定義することで、他のアクションが読み込まれる前に、ログイン画面へ遷移させることができる。

【２】ユーザーの名前をDBへ保存できるように設定する。

class ApplicationController < ActionController::Base
  before_action :authenticate_user!
  before_action :configure_permitted_parameters, if: :devise_controller?

  private
  def configure_permitted_parameters
    devise_parameter_sanitizer.permit(:sign_up, keys: [:name])
  end
end

Rails では、セキュリティ対策のため、保存のルールを予め決めておかないと保存できない仕組みになっている。deviseにおいて、emailやpasswordはデフォルトで作成されるが、nameのように自分で追加したカラムがある場合には、保存するルールを決める。
devise_parameter_sanitizerメソッドとは、deviseでユーザー登録をする場合に使用でき、「特定のカラムを許容する」メソッド。
今回の「configure_permitted_parametersメソッド」の内容の意味は、「nameカラム」を追加したので、このメソッドを使用し、「name」キーの内容の保存をpermitメソッドで許可するということ。

ユーザー情報編集機能

#ルーティングの設定
Rails.application.routes.draw do
  devise_for :users
  root to: "messages#index"
  resources :users, only: [:edit, :update]
end

#ターミナルで実行
% rails g controller users

#usersコントローラーの設定
class UsersController < ApplicationController

  def edit
  end

  def update
    if current_user.update(user_params)
      redirect_to root_path
    else
      render :edit
    end
  end

  private

  def user_params
    params.require(:user).permit(:name, :email)
  end
end

【１】ユーザー情報編集画面が表示されるように設定する。

「devise_for :users」により、基本的なルーティングは設定しなくても遷移されるが、今回のようなユーザーの編集画面を作るには「:edit」と「:update」を追加する必要がある。
ルーティングを設定したら、コントローラーを作成する。

【２】ユーザー情報が更新されるように実装する。

Userモデルの更新を行うupdateアクションをusersコントローラーに定義する。
ストロングパラメーターを使用し、user_paramsを定義する。
user_paramsの中でpermitメソッドを使用し、「name」と「email」の編集を許可する。
ユーザー情報が格納されているcurrent_userメソッドを使用して、ログインしているユーザーの情報を更新する。

【３】更新が成功するとチャット画面に遷移して、失敗するとeditページに戻ってくるように実装する。

updateアクション内で、保存できた場合とできなかった場合で条件分岐の処理を行う。
current_user.updateに成功した場合、root（チャット画面）にリダイレクトする。
失敗した場合、render :editとeditのアクションを指定しているため、editのビューが表示される。

renderとredirect_toの違いって？

renderとは、呼び出すビューを指定するメソッド。（コントローラーとビュー、どちらでも使用可。）

render	redirect_to
新たにリクエストされることなくそのままビューを表示する（レンダーからビューへ）	新たなリクエストを送信されたときと同じ動きをする（リダイレクトから、ルーティング・コントローラーを経由してビューへ）
元のインスタンス変数の値は上書きされない（今回＝フォームに入力した内容を保持したままユーザー編集画面に戻る）	元のインスタンス変数の値は上書きされる

ログアウト機能

【１】ログアウトできるようにビューにリンク先の設定を行う。

#app/views/users/edit.html.erb内
<%= link_to "ログアウト", destroy_user_session_path, method: :delete, class: 'btn'%>

「rails routes」コマンドにて、ログアウトに関するパスを探す。
ポイントとして、基本的なdeviseに関するルーティングは、元々備わっているため（今回で言えばsessionsコントローラーのdestroyアクション）ルーティングにおいて「destroy」を定義しなくても、遷移する。（ルーティング内の「devise_for :users」に備わっている。）

バリデーション機能

【１】モデルにバリデーション機能をつける。

#app/models/user.rb内
class User < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable,  :validatable

  validates :name, presence: true

end

空の場合はDBに保存しないというバリデーションを設定した。
deviseに対して後付けしたカラムは、自分でバリデーションを設定する必要がある。

積み残し（わからないところ）

<%= form_with(model: @tweet, local: true) do |form| %>※モデル
deviseに関するマイグレーションファイルは書き方がビューに影響する？（名前、Eメール、パスワードがあったとして、ユーザーに入力してもらいたい順番で書かないと順番異なるのか？）

感想

ブログにアウトプットとして書くために、もう一回見返したり考えたりすると、理解していない部分が改めて見つかるので大切だと実感。
最近、パソコン見すぎて、目が乾く。
MVCの復習を挟んだことにより、やっと、想像できるようになった。（この機能入れるなら、ルーティング、モデルだろう、という予想）
想像できるものの、実際にコードを書くと、細かい部分まで理解できてないのが悔しい。（例えば、これはアクションだからこう表記する、シンボルだからこう表記するというようなこと。）
deviseのアクションなのか、メソッドなのか、やっと理解できた気がする。メソッドに関してはもう一回、おさらいしたいな。