Rails Tutorialの第14章にある拡張機能について
Rails Tutorialをの第14章には、Tutorialを完了した人向けに、自分で機能を拡張するお題がいくつかあります。
最初のお題である、返信機能に挑戦しています。まだ作成途中ですが、できたところまで投稿します。
作る要件を確認し、仕様を作る
要件は以下のように書かれています。
Twitterには、マイクロポスト入力中に@記号に続けてユーザーのログイン名を入力するとそのユーザーに返信できる機能があります。このポストは、宛先のユーザーのフィードと、自分をフォローしているユーザーにのみ表示されます。この返信機能の簡単なバージョンを実装してみましょう。具体的には、@replyは受信者のフィードと送信者のフィードにのみ表示されるようにします。
仕様のヒントも書かれています。
これを実装するには、micropostsテーブルのin_reply_toカラムと、追加のincluding_repliesスコープをMicropostモデルに追加する必要があると思います。
要件を具体的にブレークダウンします。
・@replyが表示されるのは、以下の3者
replyの受信者
replyの送信者（自分）
replyの送信者のフォロワー
上記以外のユーザーには表示されない
・マイクロポストの先頭に「@reply ユーザーのログイン名」を入力したときに、このポストをreplyと判定
仕様を深堀する、例示されているtwitterを参考にするため調べる
Tutorialの「6.2.5 メールアドレスの一意性」を読み返したところ、大文字と小文字の区分けをするか書いてありました。
ユーザー名に大文字と小文字で区分けをすべきなのか、TaroとTAROを違うものとするかどうかです。
twitterはどうなのかネットで調べます。
内部では同じだが、入力時に区分けはするという記事が多かったです。ズバリ書いている記事が見つからなかったです。
メアドと同じ仕様で作ることにします。
この大文字小文字の機能は、最初からではなく後で追加することにしました。後から追加するのが簡単そうに見えたためです。
どういう機能を作るか、以前に追加した機能に似ているので読み返す
以前に追加した機能に似ているので、どの機能と似ているか読み返します。
13章のマイクロポストの機能に似ている
6.7章のユーザー登録の機能に似ている
6.2.5 一意性を検証する
メールアドレスの一意性
その結果をもとに、以下のような機能を考えました。
・replyで表示する／しないの判定ができる機能をmodelに追加
このpostはreplyかどうか
・@replyの入力を判別する機能をviewまたはcontrollerに追加
・ユーザー名がユニークになるように、modelとviewに追加
最後の「ユーザー名がユニーク」の機能は、最初からではなく後で追加することにしました。まずはユニークなテストデータだけで動くものを作ってみて、後からユニークにする制約の機能を付け加えればよいと考えたためです。
機能を詳しく設計する モデル
14章の14.1.1を再度読みます。id間のrelatoinのことでした。
micropostsテーブルのin_reply_toカラムと、追加のincluding_repliesスコープをMicropostモデルに追加する必要があると思います。
をヒントに、modelをどう変更するか考えます。
microposts
| 列名 | 属性 |
|---|---|
| id | integer |
| content | text |
| user_id | integer |
| in_reply_to | integer |
| created_at | datetime |
| updated_at | datetime |
in_reply_to の列を追加するとして、型は何になるか？どのユーザーか特定するのだから、idと同じでintegerと考えました。
機能を詳しく設計する メソッド
micropostのメソッドを追加するか、既存のメソッドを変更するか。
表13.1を参考にします。
user.micrposts Userのマイクロポストの集合をかえす 既存の変更
user.microposts.build(arg) userに紐付いた新しいMicropostオブジェクトを返す 既存の変更
user.microposts.find_by(id: 1) userに紐付いていて、idが1であるマイクロポストを検索する 既存の変更
replyのメソッドを追加するか、考えます。
user.microposts.create(arg,reply:user2) user2へのreplyのマイクロポストを作成する
既存のcreateメソッドを変更することにします。
機能を詳しく設計する ビュー
画面は主に2つ修正、replyを入力するところと、replyを表示するところです。
入力項目は増やす必要がない、なぜなら、contentの先頭に@replyと記入するからと考えました。
出力でreply専用の画面が必要か？
Twitterを調べます。replyは元Tweetをクリックすると別画面に移ってreplyの一覧を表示しています。replyの親子のTweetを一覧で表示しています。
ちょっと複雑なので今回はそこまではやらず、元Tweetと同じ画面に表示することにします。
画面のイメージは、モックを作るのは面倒なのでテキストだけです。
comment box : @reply michael Cum aspermatur ..
Feedの表示イメージ
@reply michael Cum aspermatur ..
機能を詳しく設計する ビューの入力エラーチェック
user_idが見つからないときは、親切な設計なら入力時にエラーを表示します。createするときにチェックするはずなのでエラーを表示することにします。
postをした後で、user_idが削除されたケースはどうするか？
このmicropostを削除するべきか。もういない人にreplyしたmicropostだけが残っているほうがよいと考え、micropostは削除しないと考えます。
所要時間
9/27から10/1までの3.0時間です。