[Tip] - An utility view to improve the performance of ForEachStore in some situations.

[tgrapperon]

Hello!
When using a top-level ViewStore as an @ObservedObject, @StateObject or even when using a WithViewStore, the invalidation scope of this object interfere with more complex View whose dependencies are out of the ViewStore scope. This can happen for example when using a ForEachStore, as the content is usually a standalone view that only depends on EachStore. If we have for example:

struct State {
  var children: IdentifiedArrayOf<Child.State>
  var value: Double
}

and then in the View:

WithViewStore(store, observe: { $0.value }) { viewStore in
  VStack {
    Slider(value: viewStore.binding(get: \.value, send: Action.setValue)
    ScrollView(.horizontal) {
      LazyHStack {
        ForEachStore(store.scope(state: \.children, action: Action.children) { childStore in
          ChildView(store: childStore)
        }
      }
    }
  }
}

Using the slider invalidates the whole WithViewStore content. This in turn causes the invalidation of the whole ScrollView itself, as all these views are using closures to define their content. Ultimately, the escaping closure of ForEachStore changes its reference, dirtying all its closure-based containers (that is LazyHStack and ScrollView). We would have the same issue with vanilla SwiftUI, as ForEach uses itself an escaping closure. Please also note that the problem is not univocally created by escaping closures, as it can happen relatively easily as soon as reference types are involved, explicitly or internally.

The first workaround is to narrow WithViewStore's reach:

VStack {
  WithViewStore(store, observe: { $0.value }) { viewStore in
    Slider(value: viewStore.binding(get: \.value, send: Action.setValue)
  }
  ScrollView(.horizontal) {
    LazyHStack {
      ForEachStore(store.scope(state: \.children, action: Action.children) { childStore in
        ChildView(store: childStore)
      }
    }
  }
}

But you can remark that we had to refactor our view hierarchy to put the VStack out of WithViewStore. This kind of modification is not always convenient to perform, especially if the "heavy" view is deep into the belly of WithViewStore's hierarchy. And when using @ObservedObject or @StateObject instead, it is impossible.

The "clean" workaround is to extract the ScrollView and its content in a standalone view:

struct ChildrenView: View {
  let store: Store<State, Action>
  var body: some View {
    ScrollView(.horizontal) {
      LazyHStack {
        ForEachStore(store.scope(state: \.children, action: Action.children) { childStore in
          ChildView(store: childStore)
        }
      }
    }
  }
}

and use ChildrenView(store: store) in place of the ScrollView in WithViewStore. But please note that this view is not expecting a Store<IdentifiedArrayOf<Child.State,…, and it performs the scope internally. This is because scoping is currently not reusing Store instances, so if we scope at the WithViewStore level, we will vend a new Store instance. This will invalidate ChildrenView dependencies, and runs its body, bringing us back to where we started.

So there is a fair amount of finesse required to work around this issue. One solution is to cook up a wrapper view that depends only on the store's instance:

public struct StoreIsolated<State, Action, Content: View>: View {
  let store: Store<State, Action>
  let content: Content
  
 public init(
  _ store: Store<State, Action>,
  @ViewBuilder content: (Store<State, Action>) -> Content
 ) {
    self.store = store
    self.content = content(store)
  }
  
  public var body: some View {
    Container(content: content)
      .id(ObjectIdentifier(store))
  }
  
  struct Container: View {
    @SwiftUI.State var content: Content
    var body: some View {
      content
    }
  }
}

I can discuss the implementation in the comments if you want, but in few words, it captures the store's instance and its related content. If and only if the store instance changes, the content is invalidated. You simply wrap the view you want to isolate:

WithViewStore(store, observe: { $0.value }) { viewStore in
  VStack {
    Slider(value: viewStore.binding(get: \.value, send: Action.setValue)
    // ---
    StoreIsolated(store) { store in 
      ScrollView(.horizontal) {
        LazyHStack {
          ForEachStore(store.scope(state: \.children, action: Action.children) { childStore in
            ChildView(store: childStore)
          }
        }
      }
    }
    // ---
  }
}

This view will not be invalidated when ViewStore emits its objectWillChange. We can make it even more resilient by removing the .id(ObjectIdentifier(store)) step. In this case, it won't be invalidated even when the store instance changes (which should probably be OK).

Please note that this wrapper isolates its content from the parent view: @Environment values or viewStore can be captured, but they won't be observed. If you "StoreIsolate" some view, it is really isolated, and its content will only reflect its store's changes.

There are other approaches to this problem. For example, one can define the Isolated ViewModifier:

extension View {
  public func isolated() -> some View {
    Isolated(content: self)
  }
}

struct Isolated<Content: View>: View {
  @State var content: Content
  var body: some View {
    content
  }
}

You activate it simply by tacking .isolated() after the view you want to isolate. The problem with this approach is that we snapshot blindly the content view only once, so it is equivalent to removing the .id(ObjectIdentifier(store)) in StoreIsolated and it won't follow Store instances changes. As I don't know if this is really a problem yet, I prefer to keep a store-instance-dependent approach. But it is clear that .isolated() makes more sense that StoreIsolated if the .id part is ultimately dropped.

It is also possible that using @StateObject allows further improvements in this area, as we can use it to construct a generic

ScopeView<State, Action, Content: View>(
  store: Store<State, Action>, 
  state: (State) -> ScopedState, 
  action: (ScopedAction) -> Action,
  content: (Store<ScopedState, ScopedAction>) -> Content
)

where the Store<ScopedState, ScopedAction> argument would be a stable instance. Because we won't have to follow them anymore (if it's even required), this would make .isolated() the best solution to the isolation problem.

I'm not proposing any PR yet, but this discussion may help give a little visibility to this potentially subtle problem.