17 params
POST /boards/10/comments リクエストボディ comment: { body: “hello” }
17-1 コントローラ側で10という情報を取得したい場合はどう書きますか?paramsを使って答えてください。(params[:board_id])
params[:id]
17-2 コントローラ側でhelloという情報を取得したい場合はどう書きますか?paramsを使って答えてください。(params[:body])
params[:comment][:body]
17-3 params.require(:user)の:userってHTMLのどこに対応したものですか?
<input type="text" name="user[:email]">
18 renderとredirect_toについて、それぞれの違いは?
renderはcontrollerのactionを経由しない redirect_toは経由する renderは画面描画時に新しくHTTPリクエストを送信しないため、対応するコントローラのアクションの中身の処理は実行されない。 redirect_toはHTTPリクエストを送信し直すため(正確に言うと、一度クライアントに返してクライアントのリクエストを投げる)、アクションの中の処理は実行される。
ちなみに無限ループが起きる時、redirect_toで302のエラーがずっとでる。
19 マイグレーション全般
migrationファイルで管理するメリットは?
どのマイグレーション(バージョン)が適用済みかをデータとして保存しており、 これによってrails migrateコマンドは、飛び石でマイグレーションが適用されているような状況でも、 適用していないマイグレーションだけを適用して管理しやすいメリットがある
20 ロールバック
ロールバックはどの様な処理ですか? migrationだとどのようなコマンドで実行するか?
・マイグレーション ファイルの状態をupからdownにする トランザクションの場合、処理を取り消して処理前の状態に戻すこと ・マイグレーションファイルの実行をなかったことにする。 rails db:rollback 1個戻る。
21 バリデーションエラー発生時の挙動
バリデーションエラーが発生したときのメッセージを、あなたならどの様に表示させますか?errorsもしくはerrors.full_messagesという言葉を使って説明してください
<% @user.errors.full_messages.each do |error| %> みたいな感じ取得して、ループさせて表示させる。
<% @user.errors.full_messages.each do |message| %> <%= message %> <% end %>
・errors - 各カラムに対し発生したエラー内容を文字列の配列(少し表現が違うらしい。)として保管したインスタンスを取得。 ・full_messages - 実際にビューに表示するのに適した文章に整形されたメッセージの配列を取得する。 ・あとはeachで配列からエラー文を1つずつ取り出し順に表示させる。
22 scope
モデルでscopeを設定するメリット何ですか?
・頻繁に使用されるクエリに名前をつけて設定しておくことができ、コードが短く、かつ直感的に理解しやすくなる。 ・複雑な検索メソッドや長いメソッドチェーンなど読みにくいものにラベルを付けることで可読性が上がり再利用しやすくなる。
23 resoursesのネスト
どんなケースでネストさせると良いか?
・あるアブジェクトが必ず特定のオブジェクトに紐づいている場合 ・モデル同士が1対多の関係にあり、それぞれのモデルのオブジェクトを個別に取り扱いたいとき。
モデル間で関連付けが設定されており、親子両方の情報をURLに含めたい場合
resources :parents do resources :children end => /parents/:parent_id/children/:id といったURLが得られる
24 application.html.erbのyieldって何をしているのか?
正直ここはあまりわかっていないので、再度視聴しなおす必要あり。
・各ページで作成したbodyタグの中の内容を持ってくる、表示する → bodyタグ全体ではなく、bodyタグの1要素の内容らしい。 ・renderによってリクエストされたviewがyieldに埋め込まれる → 「リクエストされた」という表現はおかしい
追記(6/28)
application.html
<body> <% if logged_in? %> <%= render 'shared/header' %> <% else %> <%= render 'shared/before_login_header' %> <% end %> <%= render 'shared/flash_message' %> <%= yield %> #各テンプレートファイル(ex index.html.erbやnew.html.erbなど) の内容をyieldで差し込んでいる。 <%= render 'shared/footer' %> </body>
25 他人の掲示板を編集・削除しようとした際の制御
BoardsControllerのedit update destroyアクションで Board.findを使ってリソースを取得していた場合、どの様な問題点がありますか。 またどの様な記載が望ましいですか。
・URL直打ちやターミナル操作( curl -XPOST …)での変更や削除が可能な状態になってしまう。
def edit @board = current_user.boards.find(params[:id]) redirect_to root_path if @board == nil end
・他のユーザーの掲示板も含めた全体を検索してしまっているので他人の掲示板を操作できてしまう。
current_user.boards.find(id: board_id)
26 collectionルーティング
memberとcollectionルーティングはそれぞれどの様な状況で使いますか?
・ルーティングにIDが付くかどうかの違い。 collectionではIDが付かないので、:idでurlを識別する必要がない場合用いる。 ・自動で生成される7つのアクションの他に、新たに独自のアクションを追加する場合は合わせてルーティングも設定する必要がある。 その際リソースのIDが不要なアクション(インスタンスの一覧表示など)ならcollectionを、 必要なアクション(あるインスタンスの詳細を表示など)ならばmemberを使用する。
27 has_many through
has_many through アソシエーションを設定するとどのようなうれしいことがありますか?
・中間テーブルで結びついている他のテーブルの値を、中間テーブルを経由して値取得ができる。 ・has_many :関連名, through: :中間テーブル名 でユーザーがブックマークした掲示板を取得するみたいな処理ができる。 ・多対多の関連付けを簡潔に表現できる。中間テーブルを意識せずに他方のモデルを取得できる。
ajaxとは何か。何が嬉しいか。
・JavaScriptを用い非同期通信を行う。リクエストに対し画面全体をリロードする必要がなく、変更が必要な部分だけを動的に再表示する。 リクエストに対する返答を待つ間もユーザーは操作を行うことができる。 ・非同期でサーバーと通信して、画面の1部を変えることができる。有名なサービスはGoogleMapです。 サーバーにページ全部をリクエストしなくていいので、画面が一瞬白くならない。 なので、非同期通信中にユーザーは別の作業をできる。
ps 画面遷移することないので、目が疲れない。
29 data-remote="true"によるajax処理
・remote trueにしなかった場合、HTTP通信でform内容を投げる。 一方、remote: trueの場合、ajax通信となり、~.js.erbファイルを探す。
30 debuggerを使ったブラウザの検証ツールによるJavascriptコードのデバッグ
JavaScriptのdebuggerメソッド使えてますか? JavaScriptのデバッグをターミナルではなく、ブラウザの検証ツールで行わなければならない理由を説明してください。
・JSはフロントエンド(ブラウザで動作する、DOMオブジェクトを操作する)言語なので、ターミナルには表示されない。 ブラウザ側のディベロッパーツールにしか表示されない。デバッグにはconsole.log() も使える。
31 単一resource(ルーティング)
単一リソースはどんな時に使いますか?resources との違いも説明してください。
:idを含める必要がない時 アプリケーション内でユーザーがただひとつしか操作できないものを表現するときに単数リソースを使う。 例えば、アカウント情報はそれぞれのユーザーが持っているため複数あるように思えるが、 ユーザーは自身のアカウントしか意識できない(=他人のアカウント情報は見えない)し、2つのアカウントを持つこともできない。 よって、アカウント情報には単数リソースを用いる。 反対に、記事などは一人のユーザーが複数作成できるので、普通のリソース(resources)を用いる。
32 モデルに紐づかないコントローラの実装
基礎編ではプロフィールの編集機能がUsersControllerではなくProfilesControllerで実装されていました。どのような背景があると考えられますか?
IDを必要としないため ・分離することで、UsersControllerの肥大化を防ぐため。《T》 ・プロフィールに関することを、ProfilesControllerに集約することで変更が容易になる。 (*モデルに紐付かなくても操作可能。)
# profiles_controller.rb user = User.find_by(email: current_user.email)
補足:
・SQLコマンドは最低限覚える!
・HTTPの話はもう一度視聴する。(yieldのところで言ってはる。)
追記(6/28) まずrailsはHTMLを生成している。
各テンプレートファイル(ex index.html.erbやnew.html.erbなど)の内容をyieldで差し込んでいる。 ↓ HTTPレスポンスに乗っかってクライアントに返ってくる。(このときはただの文字列) ↓ それをブラウザが自分たちに見やすいようにいい感じで解釈して 画面に表示してくれている。