This PR, much like #458, is conceptual and still TBD for #457
Additional comments 🎤
Unlike #458, this PR only supports having Conversation as the trait object while retaining the rest of the messaging logic, besides the breaking change between Conversation::recipients and Conversation::members
This object attempts to remain as a getter functionality while attempting to avoid async calls, however similar to #458, we may eventually need to cache the resolved data of the ConversationDocument and map that out to this trait object if we wish to maintain the same flow without introducing async functions into the mix.
Unlike #458, this PR only implements Conversation. It does not store its internal data inside of a lock, which means when when the conversation has an updated (eg adding/removing members, update to conversation name, etc), it would need to grab a new object by calling RayGun::get_conversation with the updated information
What this PR does 📖
Conversationinto a trait objectWhich issue(s) this PR fixes 🔨
Special notes for reviewers 🗒️
Additional comments 🎤
Conversationas the trait object while retaining the rest of the messaging logic, besides the breaking change betweenConversation::recipientsandConversation::membersConversationDocumentand map that out to this trait object if we wish to maintain the same flow without introducing async functions into the mix.Conversation. It does not store its internal data inside of a lock, which means when when the conversation has an updated (eg adding/removing members, update to conversation name, etc), it would need to grab a new object by callingRayGun::get_conversationwith the updated information