How to avoid unnecessary view refresh in ForEachStore

[fatbobman]

I use ForEachStore to split the desired Store for the subviews in the List .

All subviews in the List are refreshed after adding or modifying data to the dataset.

But instead of using ForEachStore , when using ForEach(viewState.list) , only the subviews that have changed will be refreshed.

how to avoid multiple refreshes of the view when using ForEachStore

Thanks

struct ContentView: View {
    let store: Store<TestReducer.State, TestReducer.Action>
    var body: some View {
        WithViewStore(store) { viewStore in
            VStack {
                HStack {
                    Button("Add") { viewStore.send(.appendNewItem, animation: .default) }
                    Button("Del") { viewStore.send(.delLastItem) }
                }
                List {
                    ForEachStore(store.scope(state: \.list, action: TestReducer.Action.row)) { store in
                        Row(store: store)
                    }

//       Using ForEach(viewState.list) , only the subviews that have changed will be refreshed.
//                    ForEach(viewStore.list){ item in
//                        Row1(item: item)
//                    }
                }
                .task {
                    viewStore.send(.onAppear)
                }
            }
        }
    }
}

struct Row: View {
    let store: Store<Item, RowAction>
    var body: some View {
        WithViewStore(store) { item in
            let _ = print("update \(item.id)")
            Text("id:\(item.id),count:\(item.count)")
        }
    }
}

struct Row1: View {
    let item: Item
    var body: some View {
        let _ = print("update \(item.id)")
        Text("id:\(item.id),count:\(item.count)")
    }
}

struct Item:Identifiable,Equatable{
    var id:Int
    var count:Int
}

struct TestReducer:ReducerProtocol {
    struct State:Equatable{
        var list:IdentifiedArrayOf<Item> = []
        var count:Int = 10
    }

    enum Action:Equatable{
        case onAppear
        case appendNewItem
        case delLastItem
        case row(id:Int,action:RowAction)
    }

    var body: some ReducerProtocol<State,Action>{
        Reduce{ state,action in
            switch action{
                case .appendNewItem:
                    state.count += 1
                    state.list.append(.init(id: state.count, count: state.count))
                    return .none
                case .delLastItem:
                    state.count -= 1
                    state.list.removeLast()
                    return .none
                case .onAppear:
                    let list = (0...state.count).map{Item(id: $0, count: $0)}
                    state.list = IdentifiedArrayOf(uniqueElements: list)
                    return .none
                case .row:
                    return .none
            }
        }
    }
}

enum RowAction: Equatable {}

[tgrapperon]

Hey @fatbobman!
As I'm seeing it, you're observing the entirety of TestReducer.State in WithViewStore which is usually a bad practice, as it leads to many unneeded re-renders and also often bugs. See #1340 and #1339 for more information on the problem.
In your case, WithViewStore doesn't need to observe any state at all, so you can probably quickly check if WithViewStore(store.stateless) { … } improves your situation. This is equivalent to scope your state to Void, as the following are equivalent in term of behavior:

WithViewStore(store.stateless) { … }
WithViewStore(store.scope(state: { _ in () })) { … } // Former API, now deprecated
WithViewStore(store, observe: { _ in () }) { … } // New API

[fatbobman]

Thank you for your reply.

Changing WithViewStore in ContentView to store.stateless does not improve the update problem.

WithViewStore(store.stateless) { viewStore in

I think the problem should be in ForEachStore, I don't know if it's a problem with my usage, or something else

[tgrapperon]

I see. It happens because ForEachStore vends a new Store instance each time the collection that is observed in ForEachStore changes. This is not optimal, but usually not a performance bottleneck, as this is usually a relatively low frequency event.

It is probable that one could cache and return again the same Store instances in ForEachStore, but I'm not sure it's worth the overhead in terms of performance. I'll check if I can measure something meaningful.

In any case, you should always only observe what's required by your view with WithViewStore (here, nothing, as ForEachStore handles the list observation efficiently internally). If something is problematic with your approach, this is definitely this, because even if ForEachStore would return stable stores instances, observing the entirety of Store in WithViewStore would make the whole collection re-render when an internal change occur in any row, which is definitely something you would want to avoid.

If you perform this operation (with the observe: argument, or using store.stateless in this case), I don't see anything particularly wrong with the rest of your implementation, besides the fact that having a duplicated source of truth (count and list.count) is slightly odd (but maybe required by your real-life domain).

[fatbobman]

Thanks for the suggestion, I'll limit the store in the view to only observe what needs to be used

Re-rendering all views due to changes in one view's data in ForEach can cause significant performance issues in some cases. Maybe ForEachStore should think more about this

[tgrapperon]

Re-rendering all views due to changes in one view's data in ForEach can cause significant performance issues in some cases

Please note that this is not exactly what happens here: it recomputes all the views because the collection's identifiers have changed (you added or removed a item to the IdentifiedArray). If only some view's data changes, ForEachStore will not invalidate the collection at all and only this view will be re-rendered. As adding/removing items is a relatively low-frequency operation, it shouldn't be a concern usually, especially if using a List or a LazyStack/Grid where only a dozen views will be invalidated, but if you have an example illustrating how the performance can noticeably be affected nonetheless, please share so we can use it as a baseline to improve the situation.

[fatbobman]

Indeed, ForEachStore only generates redundant computations when the amount of data in the dataset changes. It's not a problem in most cases.

When the amount of data is large and the amount of data changes at a high speed, I may use this way to avoid unnecessary calculations

WithViewStore(store, observe: { $0.list }) { viewStore in
    List {
        ForEach(viewStore.state) { item in
            Row(store: store.scope(state: { _ in item },action: {TestReducer.Action.row(id: item.id, action: $0)}))
        }
    }
    .task {
        viewStore.send(.onAppear)
    }
}

[mbrandonw]

There's definitely a lot more we can be doing to make some of the default views in TCA more performant, but I think a lot of hinges on being able to use @StateObject and hence dropping iOS 13 support. We even had a release of TCA where we shimmed @StateObject so that we could use it on iOS 13, but unfortunately it had some problems in practice so we reverted.

As an example, here's something I just experimented with to see how each row of a ForEachStore can stop producing a new store for each row when data is added/removed. It seems to work, but we can't even think about using this until we drop iOS 13 support.

It's also worth mentioning, and maybe @tgrapperon already did, that although the rows are recreated when data is add/removed, that is not the case when data only changes inside the row. This has always been the case in ForEachStore, but recently it was made very efficient thanks to a PR (#1307) from @tgrapperon. So, if your rows had more complex behavior inside and state was changing, you would not be seeing all the print statements that you see with adding/removing.