-
Notifications
You must be signed in to change notification settings - Fork 319
refactor(timeline): enhance the Timeline::send()
and Timeline::send_reply()
APIs when the timeline is threaded
#5427
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## main #5427 +/- ##
==========================================
+ Coverage 88.85% 88.87% +0.02%
==========================================
Files 333 333
Lines 91356 91400 +44
Branches 91356 91400 +44
==========================================
+ Hits 81172 81231 +59
+ Misses 6360 6347 -13
+ Partials 3824 3822 -2 ☔ View full report in Codecov by Sentry. |
This sounds sensible and much easier than fiddling with |
…relationship for thread foci
…thread relationship too
aed804d
to
0a75d73
Compare
Stefan identified a few issues, so might as well add some tests later:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new API looks great and I have a PR for EX adopting it here element-hq/element-x-ios#4344
I did leave a comment about polls not working as expected but that's not necessarily a blocker as we didn't have an API for sending them in threads before either.
Same would apply to stickers I guess if we were to ever implement sending support for them.
This should make it simpler to send in-thread messages and in-thread replies in the future, but not mandating that the caller passes so much information.
Timeline::send()
Timeline::send_reply()
which only takes anOwnedEventId
param instead of aReply
Timeline::send()
.)The improvement is notable in the code of
multiverse
, for instance, where sending an event is now the same code between a regular or a threaded timeline.If the threaded timeline isn't empty, it'll correctly use the latest in-thread event as the replied-to fallback event id (a check has been added in one test for that, and this avoids the mess observed in #5422). We could go one step further and trigger a pagination if the threaded timeline was empty; we'll see if we'll ever need it.
cc @Johennes, curious to get your thoughts on the new API!
Fixes #5216