【Rails】お気に入り機能の実装(多対多の関連付け)【DIVE INTO CODE】

更新日:

「DIVE INTO CODE」学習記録 16日目

こんにちは。

16日目。ブログアプリにお気に入り機能を実装。Modelの関連付け。

学習内容

【アソシエーション】

  • アソシエーション シリーズ課題(ブログお気に入り機能作成)

 

感想

今回は前回からの続きのアソシエーションの課題で1日使いました。

また結構悩まされました。

 

課題合格条件が複数項目あり、

  1. 今まで作成してきたブログ機能に追加する形でお気に入り機能をつけること。
  2. アソシエーションの実装により、ユーザーとブログ記事を紐付けすること。
  3. ユーザーのブログ投稿時、そのユーザーのidをブログのuser_idテーブルに入れる処理を行うこと。
  4. ブログ投稿者以外には編集ボタンと削除ボタンを表示させないようにすること。
  5. ブログのお気に入り機能を実装すること
  6. お気に入りしたブログ一覧を、ユーザー画面に反映させること。

を満たさないと合格できません。

確かに全てブログだったら当然ついてる機能だなと。

 

詰まったのはまさかの3番目。

「ユーザーのブログ投稿時、そのユーザーのidをブログのuser_idテーブルに入れる処理を行うこと。」

 

あっという間に詰まりました。

いくらテキスト通りコード書いてもブログ投稿時に

 

「User must exist」

 

が出てきてしまい、

ユーザーいないからブログ投稿できませんよ、

って何回やっても言われ続けました。

 

 

ログインは間違いなくしてる。

 

blogコントローラのcreateアクションにユーザーid値を入れるための

@blog.user_id = current_user.id

というコードもしっかり書いた。

 

セッションヘルパー内で定義した「current_user」メソッドがblogコントローラでも使えるように、

「ApplicationController」に「include SessionsHelper」も書いてある。

そもそもログインのバリデーションでも「current_user」使ってるし、

そっちはしっかり反映されてるからそこは問題ではない気がする。

 

blogテーブルにはしっかり「user_id」カラムを付け足した。

マイグレーションもした。

スキーマファイルにもしっかり書いてある。

コンソールで「$ Blog.column_names」って打つとBlog内のカラム一覧がでるみたいだ。

そこ見ても「user_id」はカラムとしてしっかり入っていることが確認できる。

 

スペルミスもしてない。

 

わからん、やべーな。

 

ってなりました。

 

仕方ないから最終手段のDICの過去の質問投稿一覧みてました。

同じような質問してる人もいましたが、

その人はuser_idカラムをblogテーブルにつけてなかったみたいだ。これとは違うな。

 

わからんな。もう一回スペル確認するか。

とりあえずblogコントローラを開いて眺めてたとき、

 

createアクションのずっと下の方にconfirmアクションを発見。

 

そういえばこんなん作ったな、

ていうかブログ投稿するときってconfirm画面を間に挟ませてたな。

 

ここにも、

@blog.user_id = current_user.id

書いてみたらいいんじゃないのか。

 

って思いやってみたら、あっさりブログが投稿可能になりました。

 

うわー、しんど。

ここかよ、気づかんわ。

 

なんか変なところで捕まった感強かったです。

テキストには書いてないんですよ、createアクションに追加しましょう、しか。

 

ここクリアした頃には気づいたら2時くらいになってて。

もはや意地になってました。時間の無駄遣い。

 

次、

「ブログ投稿者以外には編集ボタンと削除ボタンを表示させないようにすること。」

 

ここは割とすんなりいきました。

 

直接htmlに書き込めばいいな。条件分岐ってヒントも出てるし。

blogテーブルからuser_id引っ張ってくる書き方どうしよう。

 

過去のテキストで同じような書き方してるものを手本に、

htmlに条件分岐を書いて、編集ボタンと削除ボタンのコードを挟むことで解決。

 

「ブログのお気に入り機能を実装すること」

「お気に入りしたブログ一覧を、ユーザー画面に反映させること。」

ここもいろいろ試行錯誤したらできました。

 

ユーザー情報から中間テーブルを経由してブログ情報を引っ張ってくる必要があります。

まさにアソシエーションの「多対多」。

 

ここもテキストでは逆のパターンしか書いてなくて。

なるほど。これと逆を考えて書きなさいよ、ってことね。

 

DICのテキスト傾向、

「自分で考えなさい」

が最近さらに強くなってる気がします。

 

真似て書いて何回かやってるうちにここも無事解決。

なんやかんや一番時間使ったのは最初に詰まったところでした。

 

最後のherokuへのデプロイでもまた詰まったんですけど、

いっつもherokuで詰まって恥ずかしくてあまり言いたくないので省略します。

 

heroku嫌いですわ。せっかく完成したやつをうまく反映してくれんときの「うわー」感。

 

heroku対策はひたすらネットで調べたので、今回は自己解決ができました。

 

今回はこんな感じで。

次回はメール送信機能です。

 

以上ありがとうございました。

-DIVE INTO CODE
-, , , , ,

Copyright© s u p ? , 2019 All Rights Reserved.