概要
現在のリノートの実装:
- 元の投稿Aが存在するとき,それをリノート(引用ではない)するとリノートである
B ができる
- さらに,
B をリノート(引用ではない)すると Cができる
- APIではリノートの元投稿はID参照のみを返すので,
Cを取得するとBが元の投稿という扱いになる
- しかし,
Bは引用ではないためcontentが空文字列であり,(attachmentを含まない場合は)不正なデータができることになる
現在
const A = Note.new(...)
const B = A.renote(...)
const C = B.renote(...)
B.getOriginalNoteID() // -> A
C.getOriginalNoteID() // -> B
修正後
const A = Note.new(...)
const B = A.renote(...)
const C = B.renote(...)
B.getOriginalNoteID() // -> A
C.getOriginalNoteID() // -> A
現在のリアクションの実装:
- 元の投稿
Aと(引用ではない)リノートBがあるとき
Bに対してリアクションするとBにのみリアクションが付く
修正内容:
Bをリノートするときの元投稿はAであるものとして考える
- ある投稿をリノートするとき,それ自体がrenoteであるときはその参照先をリノートした扱いにする
- ただし,投稿が引用の場合はそれ自体をリノートした扱いにする
BにしたリアクションはAにしたものとして考える
- (一般的にリアクションの通知はBのauthorにもAのauthorにも飛ぶが,このPRでは考えないことにする)
→ Bの状態
↓ Bに対する操作 (Cが生成される操作)
| / |
Renote |
Quote |
| Renote |
Aを参照 |
Bを参照 |
| Quote |
Aを参照 |
Bを参照 |
追加情報
- メモ: RenoteServiceに書くロジックではなく,Noteモデル自体に書くコアロジックにすべきだと思う
- そもそもNoteとRenotedとQuotedを別のモデルとして扱っても良い気がする
- まず最初に
Note.isRenote()(isThisRenoteにすべき?) / Note.isQuoteのような判定関数を作るのがよさそう
概要
現在のリノートの実装:
BができるBをリノート(引用ではない)するとCができるCを取得するとBが元の投稿という扱いになるBは引用ではないためcontentが空文字列であり,(attachmentを含まない場合は)不正なデータができることになる現在
修正後
現在のリアクションの実装:
Aと(引用ではない)リノートBがあるときBに対してリアクションするとBにのみリアクションが付く修正内容:
Bをリノートするときの元投稿はAであるものとして考えるBにしたリアクションはAにしたものとして考える→ Bの状態
↓ Bに対する操作 (Cが生成される操作)
追加情報
Note.isRenote()(isThisRenoteにすべき?) /Note.isQuoteのような判定関数を作るのがよさそう