Post APhO5rbCSTiCIr5Pyi by jjoelson@mastodon.social
 (DIR) More posts by jjoelson@mastodon.social
 (DIR) Post #APhO5mX7IETUak8aQ4 by jjoelson@mastodon.social
       2022-11-16T19:10:30Z
       
       0 likes, 0 repeats
       
       Does SwiftUI really not have a way to insert items at the top of a list without changing which items are visible?It feels bad that I waited for SwiftUI's 4th version to try it in a serious way and I still hit a "back to UIKit" brick wall with the very first thing I tried. 😞#SwiftUI #Swift
       
 (DIR) Post #APhO5noAYJi2Xv7idc by thattridentdude@mastodon.online
       2022-11-16T20:31:07Z
       
       0 likes, 0 repeats
       
       @jjoelson Maybe I’m misunderstanding what you’re trying to do but doesn’t .insert(_, at:) work for your purposes as demonstrated by @twostraws in this article: https://www.hackingwithswift.com/books/ios-swiftui/adding-to-a-list-of-words
       
 (DIR) Post #APhO5pJOxgHpD4kAxU by jjoelson@mastodon.social
       2022-11-16T22:57:19Z
       
       0 likes, 0 repeats
       
       @thattridentdude @twostraws I'm probably describing it poorly!In Paul's example, each time you insert a row the existing rows get pushed down. Inserting many rows at once would cause all of the visible rows to get pushed off screen.What I want is for the newly inserted rows to appear off screen above the existing rows. In UIKit you can do this by manually setting the table view's content offset after calling reloadData()
       
 (DIR) Post #APhO5qQApzIWeMv69Y by ole@chaos.social
       2022-11-17T10:46:14Z
       
       0 likes, 0 repeats
       
       @jjoelson @thattridentdude @twostraws I can sort of make it work with ScrollViewReader (if this is what you mean), but only with `.navigationBarTitleDisplayMode(.inline)`. And the animation is ugly. https://gist.github.com/ole/ca325b65013bc6cdf4b8e168eabd0572
       
 (DIR) Post #APhO5rbCSTiCIr5Pyi by jjoelson@mastodon.social
       2022-11-17T14:45:00Z
       
       0 likes, 0 repeats
       
       @ole @thattridentdude @twostraws Thanks for the tip!Aside from the limitations you mention, I think this only works if you’re already scrolled to the top, because you’re grabbing the first item in the array to scroll to. I don’t think List has a general mechanism for identifying which rows are currently visible or their current offset from the top (?)
       
 (DIR) Post #APhO5tB2ahyXCIrYTw by ole@chaos.social
       2022-11-17T14:59:38Z
       
       0 likes, 0 repeats
       
       @jjoelson @thattridentdude @twostraws You can probably track this manually with `.onAppear`/`.onDisappear` on each row, but it’d be messy. Yeah, SwiftUI still doesn’t make it easy if you want to stray from the track.
       
 (DIR) Post #APhO5vA3DMN7LoPnDU by shadowfacts@social.shadowfacts.net
       2022-11-17T15:27:42.187107Z
       
       0 likes, 0 repeats
       
       @ole @jjoelson @thattridentdude @twostraws it’s been a while since I checked, but iirc, onAppear/Disappear would be more accurately called onMount/Unmount since they’re fired for everything in the list at once, rather than when individual views scroll in/out of the viewport
       
 (DIR) Post #APhPuj2Q9BysTUdSKm by ole@chaos.social
       2022-11-17T15:30:10Z
       
       1 likes, 0 repeats
       
       @shadowfacts @thattridentdude @jjoelson @twostraws For List on iOS 16, onAppear/onDisappear fire as rows are scrolled in and out of the viewport. I tested this a about a month ago. Other container views may behave differently.
       
 (DIR) Post #APhX8lu4zQ6X5xNXWa by jjoelson@mastodon.social
       2022-11-17T16:06:21Z
       
       1 likes, 0 repeats
       
       @twostraws @ole @thattridentdude @shadowfacts There has been a lot of variation over the last few years in how onAppear/onDisappear behave and it’s never clear to me what the intended behavior is versus bugs versus incidental behavior. So I’d be hesitant to trust this unless it’s documented. 😅Also, knowing the first visible row isn’t sufficient; I need to know it’s offset to avoid a jump!
       
 (DIR) Post #APhX8mZYVDHVAamfAm by jjoelson@mastodon.social
       2022-11-17T16:17:13Z
       
       1 likes, 0 repeats
       
       @thattridentdude @ole @twostraws @shadowfacts Ultimately I think SwiftUI needs to give up on its declarative purity and add hooks into view building/updating so we can control things imperatively if necessary.  There needs to be a middle ground between “100% declarative” and “rewrite in UIKit”. Flutter does this right imo:- Widget lifecycle hooks ✅- Widgets like ListView have controller objects âœ