From d4ed146cd77710a1ec6fcc38441b03b015f9562a Mon Sep 17 00:00:00 2001 From: Danila Fedorin Date: Thu, 29 Jul 2021 13:40:02 -0700 Subject: [PATCH] Add implementation thoughts --- doc/impl-thoughts/REPLIES.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/impl-thoughts/REPLIES.md diff --git a/doc/impl-thoughts/REPLIES.md b/doc/impl-thoughts/REPLIES.md new file mode 100644 index 00000000..eac5b7ea --- /dev/null +++ b/doc/impl-thoughts/REPLIES.md @@ -0,0 +1,17 @@ +If we were to render replies in a smart way (instead of relying on the fallback), we would +need to manually find entries that are pointed to be `in_reply_to`. Consulting the timeline +code, it seems appropriate to add a `_replyingTo` field to a `BaseEventEntry` (much like we +have `_pendingAnnotations` and `pendingRedactions`). We can then: +* use `TilesCollection`'s `_findTileIdx` to find the tile of the message being replied to, + and put a reference to its tile into the new tile being created (?). + * It doesn't seem appropriate to add an additional argument to TileCreator, but we may + want to re-use tiles instead of creating duplicate ones. Otherwise, of course, `tileCreator` + can create more than one tile from an entry's `_replyingTo` field. +* Resolve `_replyingTo` much like we resolve `redactingEntry` in timeline: search by `relatedTxnId` + and `relatedEventId` if our entry is a reply (we can add an `isReply` flag there). + * This works fine for local entries, which are loaded via an `AsyncMappedList`, but what + about remote entries? They are not loaded asynchronously, and the fact that they are + not a derived collection is used throughout `Timeline`. +* Entries that don't have replies that are loadeded (but that are replies) probably need + to be tracked somehow? + * Then, on timeline add, check new IDs and update corresponding entries