feat: optimize FeedDetailPage list to reduce jumping #136
Conversation
Use opacity animation instead of hiding/showing sections: - Sections remain in layout (no height jumps) - Fade in via opacity 0->1 when ready - Postscripts fade in when content is ready - Replies fade in 150ms after content - Faster easeIn animation (0.15s) This avoids layout recalculation and position jumping. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
graycreate
force-pushed
the
feature/feed-detail-list-optimization
branch
from
4883212 to
b2f6419
Compare
There was a problem hiding this comment.
Pull request overview
This PR optimizes the FeedDetailPage to reduce visual jumping by implementing a staged loading approach for list sections. Content appears first, followed by postscripts, and then replies after a short delay.
Key Changes:
- Added
repliesReadystate variable to control reply section visibility timing - Implemented cascading load effect with 150ms delay between content and replies
- Added easeInOut animations for smooth transitions between states
| @State private var contentReady = false | ||
| @State private var repliesReady = false |
There was a problem hiding this comment.
The state variables contentReady and repliesReady are not reset when new data is loaded. When a user pulls to refresh or when data is reloaded, these states remain true, preventing the staged appearance animation from running again. Consider adding an onChange handler that resets these states when state.model changes or when a refresh begins.
| DispatchQueue.main.asyncAfter(deadline: .now() + 0.15) { | ||
| withAnimation(.easeInOut(duration: 0.2)) { | ||
| repliesReady = true | ||
| } | ||
| } |
There was a problem hiding this comment.
The DispatchQueue.main.asyncAfter closure captures self implicitly, which could lead to a retain cycle if the view is dismissed before the delay completes. Additionally, if the view is dismissed or refreshed before the 0.15 second delay completes, the delayed closure will still execute and set repliesReady = true on a potentially stale view. Consider using a weak self capture or canceling the delayed work when appropriate.
| .animation(.easeIn(duration: 0.15), value: contentReady) | ||
| .animation(.easeIn(duration: 0.15), value: repliesReady) |
There was a problem hiding this comment.
The animation modifier is applied to the entire List based on contentReady and repliesReady state changes. This causes all changes to the List to be animated with easeInOut, not just the appearance of content and replies. This could lead to unintended animations for other state changes, such as when loading more replies or when the reply section header appears. Consider applying the animation only to the specific views that should be animated, or use a more targeted approach.
| .animation(.easeIn(duration: 0.15), value: contentReady) | |
| .animation(.easeIn(duration: 0.15), value: repliesReady) |
Code Coverage Report ❌Current coverage: 33.94% |
Summary
Optimize the FeedDetailPage list loading to reduce visual jumping when content populates.
Changes
repliesReadystate to control reply section visibilityHow it works
The cascading load effect prevents all sections from appearing at once, which was causing jarring list jumps. Each section appears in sequence with a slight delay, creating a smoother user experience.
Test plan
🤖 Generated with Claude Code