-
Notifications
You must be signed in to change notification settings - Fork 117
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
Use a VStack on the timeline #332
Conversation
Replace edge publishers with a binding.
4ea4efb
to
80a392f
Compare
Generated by 🚫 Danger Swift against 80a392f |
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
ElementX/Sources/Screens/RoomScreen/View/Timeline/ImageRoomTimelineView.swift
Show resolved
Hide resolved
Codecov ReportBase: 32.40% // Head: 32.29% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## develop #332 +/- ##
===========================================
- Coverage 32.40% 32.29% -0.12%
===========================================
Files 266 267 +1
Lines 17530 17593 +63
Branches 9617 9671 +54
===========================================
Hits 5681 5681
- Misses 11677 11738 +61
- Partials 172 174 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
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.
This looks great! 🚀
This PR switches from a
LazyVStack
to a regularVStack
for the timeline. This fixes various issues seen with the lazy stack not being able to properly estimate its content size (more specifically that is doesn't seem to cache previous item heights as part of this estimate).ReversedScrollView
has been customised to be specific for the timeline and renamed accordingly.One tradeoff of this change is that memory usage will be higher than a LazyVStack when back paginating a lot in a room. In my testing an heavy amount of back pagination (mainly text items) resulted in around 500MB of memory usage which doesn't seem unworkable, but in the future we could put a limit on the number of items shown and start removing items as you scroll back.