Ole BegemannNew article: Understanding SwiftUI view lifecycles https://oleb.net/2022/swiftui-view-lifecycle/
Ralph Waldo Pickle Chips@ole I could probably test this myself, but does .task have the same semantics as .onAppear, or is it called only once at the beginning of the view's lifetime?
@shadowfacts Good question. .task (without passing an id) has the same semantics as .onAppear. The only difference is that .task may be called a few frames later because it executes its action async.
melle@melle Thanks!
Alejandro Martinez@ole I’ve tried the other day and was pretty cool. It help me formalize my idea of lazy grids. So they do really reuse views don’t they? I was mever sure if lazy means ‘load lazy but once is loaded is never gone’ or if it was actually reusing a pool like tableview does.
@alexito4 It’s hard to say. Unlike List, LazyVStack doesn’t seem to use a UICollectionView under the hood. If you look at it in the Xcode view debugger, there’s a LazyVGridLayout with a bunch of children, and I never see more than about twice the number of children in there than are currently on screen. But I have no idea if this means that it uses a reuse pool.
@ole exactly. i've never find any definitive answer to it so I'm always a bit hesitant to rely on it. Let's say I trust it less than a collection view :D
Thomas Grapperon@ole @alexito4 From my experience, it also needs a parent ScrollView with which it communicates. It then seems to load (or keep) views in ±1 screen height (or width).
Having ScrollView>AnyView>Lazy>ForEach breaks the `ScrollView/Lazy` relation, and `ForEach` then loads all its content. This clearly points away from `UICollectionView`.
I don't know if they effectively reuse stuff internally, but it shouldn't be a concern for us anymore.
Having ScrollView>AnyView>Lazy>ForEach breaks the `ScrollView/Lazy` relation, and `ForEach` then loads all its content. This clearly points away from `UICollectionView`.
I don't know if they effectively reuse stuff internally, but it shouldn't be a concern for us anymore.
@tgrapperon @ole that's interesting. well at least now I will try to keep the scroll/lazy relation direct for sure!
I personally still consider it a concern until it's behaviour is properly documented :P
I personally still consider it a concern until it's behaviour is properly documented :P
@alexito4 @ole
The `ScrollView/Lazy` was something discovered while trying to implement a `WithViewStore` backed by `StateObject` in TCA, as `ViewBuilder` wrapped the iOS 14 "limited availability" branch with `AnyView`. So I would be cautious with `#if available` near `Lazy` things. You can have `AnyView` around the whole `ScrollView`, or inside `ForEach`, but not in between. It can be tricky sometimes if the branching is hidden in a `ViewModifier`.
The `ScrollView/Lazy` was something discovered while trying to implement a `WithViewStore` backed by `StateObject` in TCA, as `ViewBuilder` wrapped the iOS 14 "limited availability" branch with `AnyView`. So I would be cautious with `#if available` near `Lazy` things. You can have `AnyView` around the whole `ScrollView`, or inside `ForEach`, but not in between. It can be tricky sometimes if the branching is hidden in a `ViewModifier`.
@tgrapperon yes exactly... but that's kinda my point. i'm not sure how much I do care about lazy if it doesn't ensure reusing.
fine, if users won't scroll it won't take memory, but if they do it's actually worse than loading at once xd anyway, hope for the future i guess.
fine, if users won't scroll it won't take memory, but if they do it's actually worse than loading at once xd anyway, hope for the future i guess.