hiroro-work commented 6 years ago

リソース生成

[x] Home
[x] User
[x] Tweet
[x] Reply
[x] Retweet

機能実装

[x] アカウント作成
[x] アカウント削除
[x] サインイン
[x] サインアウト
[x] フォロー
[x] アンフォロー
[x] ツイート（テキスト）
[x] ツイートへのリプライ（テキスト）
[x] リツイート
[x] リプライへのリプライ（テキスト）
[x] リツイートへのリプライ（テキスト）
[x] リツイートにコメントを付加

テストコード

rspec/system

[x] header
[x] footer
[x] home_index
[x] user_show
[x] tweet_show
[x] reply_show
[x] retweet_show

hiroro-work commented 6 years ago

DB作成
- PostgreSQLでcreate database tubtter_development
Home controller
- rails generate
- rootにhome#indexを設定 (for devise)
User scaffold
- rails generate
- rails generate devise User

hiroro-work commented 6 years ago

deviseのviewはdevise-bootstrap-viewsで作成 $ rails generate devise:views:bootstrap_templates

hiroro-work commented 6 years ago

ログイン後にuser_pathに飛ぶようにApplicationControllerでafter_sign_in_path_forをオーバライド。 routesでuser_root指定する方法もあったけど、こっちだとuser_pathにidが指定されず UsersControllerで対処が必要だったので上記の方法を採用。

ちなみにroutes.rbでの対応は以下のような感じ

authenticated :user do
  root to: 'users#show', as: :user_root
end

hiroro-work commented 6 years ago

Tweetのshow.html.haml作成中

hiroro-work commented 6 years ago

ReplyはUserの下に置いたほうがいいかな。User消えたらReplyも消える感じで。んでTweetとも紐づける。

hiroro-work commented 6 years ago

acts_as_followerはmigrateファイルのActiveRecord::Migrationのおしりに[5.2]をつけないとdb:migrateで失敗した。

hiroro-work commented 6 years ago

deviseのregistrations/edit画面で一回更新エラーした後にbackしてbackしたら、存在しないusersに遷移しようとするので、とりあえずedit.html.hamlの最後のリンクをコメントアウト

hiroro-work commented 6 years ago

Herokuにmaster以外のブランチをpushする場合は $ git push heroku {branch name}:master $ heroku run rails db:migrate

hiroro-work commented 6 years ago

質問

TweetとReplyは同じモデルにしちゃってもいいかな？ Replyに対するReplyを考えるとそっちのほうがよい？（何に対するReplyかをカラムとして持つときにreplyかtweetのどっちかが入ってるみたいな実装はコードが複雑になりそうでよくなさそう）

Reply機能をTweetモデルで実現。
TweetモデルにreferencesでTweetモデルをparentみたいなカラムとして持たせる感じ？
できるのかな？
 t.references :parent, foreign_key: { to_table: :tweets }
こんな感じでいけそうといううわさも。

それだとTweetコントローラが大きくなっちゃうからコントローラとしてはReplyControllerみたいの作ったほうがいいのかな？それとも1つのテーブルを複数のモデルで共有してそれぞれにコントローラ作るようにすればいいのかな？（できるかはわからないが）

TweetとReplyのidを共通化して、TweetとReplyに一発でreferenceをはるようなことはできたりするのかな？親モデル作って継承すれば行けそうだけど、Railsモデルで継承は微妙といううわさも。

回答

ReplyはTweetモデルで実現したほうが良い。

hiroro-work commented 6 years ago

「userのreplies」と「tweetに対するreplies」を表示したい場合、 ReplyControllerのindex的なアクションを複数つくるのがよいか、それとも、 UserControllerとTweetControllerにrepliesを表示するアクションを作るのがよいか？

とりあえず今とのころはtweetに対するrepliesはtweetのshowで表示してるから、 replyのindexとしてuserのrepliesを表示する機能を実装しておこう（暫定対処）。

user配下とtweet配下にコントローラを分けてやれば両方のindexを作れる？（本当にできるかは試してないから不明）

hiroro-work commented 6 years ago

replyは全アクションをtweetの下に持っていこうと思ったけど、そうすると削除されたtweetに対するreplyを残すことができなかったので、作成後のアクションはuserの下に持っていく方向で。

hiroro-work commented 6 years ago

Retweetもtweetモデルを更新して実現できそうだけど、とりあえずはreplyと同じ要領でretweetモデル作って実装する方向で。

hiroro-work commented 6 years ago

質問

Viewにてメインで操作しているモデルのインスタンスからたどれるモデルの場合、メインモデルからたどる形で参照したほうがよい？参照したいモデルのインスタンスが存在するのであればそちらを参照したほうがよい？（@userと@tweetがあって、userモデルは@userからも@tweet.userからも参照できるような場合）

回答

@userが明らかに存在しているところでは@userを使用する。

hiroro-work commented 6 years ago

ReplyとRetweetのedit/updateはUserのしたに持ってきて、 new/createと同じパスでform統一できるようにしたほうがよいかも。

hiroro-work commented 6 years ago

質問

rspecのfeatures/systemはどの単位でファイル分割するのがよい？ # 画面単位？: 画面上にある機能をテスト # モデル単位？: モデルの機能をテスト

backgroundのまとめやすさ考えたら画面単位のほうがよさそう？

回答

関連する機能の単位でファイル分割することが多い。画面単位でも問題ないが人によってはレビューで質問してくるかも。

hiroro-work commented 6 years ago

acts_as_followerを使ってるとrspec実行時に以下のエラーメッセージが出力される。

DEPRECATION WARNING: Setting custom parent classes is deprecated and will be removed in future versions.

プルリクがマージされていない模様．．．

https://github.com/tcocca/acts_as_follower/pull/89 https://github.com/tcocca/acts_as_follower/pull/93

プルリクを参考にモンキーパッチを作って対処。

hiroro-work commented 6 years ago

Chrome headlessだとCapybaraのpage.accept_confirmがうまく動かないっぽい。とりあえず、page.accept_confirm do endを削除してclick_onを直で実行するようにしたらテストがパスするようになったので暫定的にこの形で。

click_on '削除'
# page.accept_confirm do
#   click_on '削除'
# end

capybaraとchromedriver-helperを最新バージョンにしてみたけどダメだった。

capybara (3.7.2)
chromedriver-helper (2.0.0)

ちなみにdata-confirm-modal入れてない状態だと下記でテストパスしてた。

page.driver.browser.switch_to.alert.accept

data-confirm-modal入れるとポップアップがふわっとした感じになるからタイミング的な問題なのかな？ ⇒ 直前にsleepを10秒まで入れてみたけどダメだったのでタイミングでもないのかな。。 ⇒ data-confirm-modal入れるとモーダル画面がhtmlになっちゃうからaccept_confirmで　引っかからなくなってしまうらしい。　なので暫定対処のとおりいきなりclick_on '削除'でOK ⇒ と思ったらgem: headless削除したらタイミングでclick_on '削除'が失敗するように。。。 ⇒ click_onの前にモーダル画面をfindすることで対処。

hiroro-work commented 6 years ago

acts_as_followerは古いのであまり使わないほうがよいということで、フォロー機能は自力で実装。

以下の3パターンで迷ったが1の実装方法で行く方向で。 # ちなみにRailsチュートリアルは2で実装。 # モデルのメソッドは受動的/能動的どちらがよいか迷いどころ。 # 迷うくらいならということでUserの下にFollowersリソースを置いて、 # create/destroyをそのユーザに対するfollow/unfollowって感じで実装する方向で。

前提: followee/follower（実体はUser）のリファレンスを持つRelationshipモデルを作成

1. FollowersController作ってcreate/destroyでfollow/unfollow機能を実現。
2. Userモデルのメソッドでfollow/unfollow（インスタンスユーザが他のユーザをfollow/unfollow）を実装。
3. Userモデルのメソッドでfollow/unfollow（他のユーザがインスタンスユーザをfollow/unfollow）を実装。

destroyのurl/path指定のときにrelationshipインスタンスが必要なのがいやだったので create/destroyはfollowersじゃなくてfollowerの下に移動。

結局create/destroy内で呼び出すfollow/unfollowメソッドをUserモデルに実装。

hiroro-work commented 6 years ago

中の実装変えてもrspecのsystemテスト普通に動くの感動だ～。やっぱsystemテストで自動テストがよさそうだな。

hiroro-work commented 6 years ago

referencesがデフォルトでrequired: trueとは。。。

hiroro-work commented 6 years ago

tweet/replyの画面周りをもうちょいちゃんとしよう。（親がいるのにtweetとして表示されちゃってるところとか）いっそ表示は統一するか？

あとReplyモデルは削除しよう。DBも。

hiroro-work commented 6 years ago

replyのparent_tweetを削除したらtweetになっちゃうのはとりあえずよしとしておこうかな。 replyだった証みたいなカラムをTweetモデルに追加すればparent_tweet削除されても replyのままにできるけど、とりあえずは保留で。

hiroro-work commented 6 years ago

画像アップデートできるようになったけど、入力フィールドがカッコ悪い。。 bootstrap-fileinputあたり使えばいい感じにできそう？

hiroro-work / tubtter

TODO #1

リソース生成

機能実装

テストコード

rspec/system

質問

回答

質問

回答

質問

回答