ForEachStore calls computed property when no state change occurs

[kuglee]

Hi!

I have a computed property named sortedAppListItems in the model that returns the appListItems IdentifiedArray sorted. This property is used in a ForEachStore.
The problem is when the Add button is clicked this property is evaluated by the ForEachStore although no state change occurs in the model because the addButtonPressed doesn't update the state.

Is this supposed to work like this?

SSCCE:

import ComposableArchitecture
import SwiftUI

@main struct ListTestApp: App {
  var body: some Scene {
    WindowGroup {
      AppListView(store: Store(initialState: AppListReducer.State(), reducer: AppListReducer()))
    }
  }
}

public struct AppListItemReducer: ReducerProtocol {
  public init() {}

  public struct State: Equatable, Identifiable, Hashable {
    public let id: UUID

    public init(id: UUID) { self.id = id }
  }

  public enum Action: Equatable { case test }

  public var body: some ReducerProtocol<State, Action> {
    Reduce { state, action in
      switch action {
      case .test: return .none
      }
    }
  }
}

public struct AppListItemView: View {
  let store: StoreOf<AppListItemReducer>

  public init(store: StoreOf<AppListItemReducer>) { self.store = store }

  public var body: some View { WithViewStore(store) { viewStore in Text(viewStore.id.uuidString) } }
}

public struct AppListReducer: ReducerProtocol {
  public init() {}

  public struct State: Equatable {
    public var appListItems: IdentifiedArrayOf<AppListItemReducer.State>

    public init(appListItems: IdentifiedArrayOf<AppListItemReducer.State> = []) {
      self.appListItems = appListItems
    }

    var sortedAppListItems: IdentifiedArrayOf<AppListItemReducer.State> {
      // do computationally expensive sorting

      print("sorted")

      return appListItems
    }
  }

  public enum Action: Equatable {
    case addButtonPressed
    case appListItem(id: AppListItemReducer.State.ID, action: AppListItemReducer.Action)
  }

  public var body: some ReducerProtocol<State, Action> {
    Reduce { state, action in
      switch action {
      case .addButtonPressed: return .none
      case .appListItem(id: _, action: _): return .none
      }
    }
    .forEach(\State.appListItems, action: /Action.appListItem(id:action:)) { AppListItemReducer() }
  }
}

struct AppListView: View {
  let store: StoreOf<AppListReducer>

  public init(store: StoreOf<AppListReducer>) { self.store = store }

  public var body: some View {
    VStack {
      WithViewStore(store) { viewStore in Button("Add") { viewStore.send(.addButtonPressed) } }
      ForEachStore(
        self.store.scope(state: \.sortedAppListItems, action: { .appListItem(id: $0, action: $1) })
      ) { AppListItemView(store: $0) }
    }
  }
}

[tgrapperon]

Hey @kuglee! I might be missing something, but it seems that all you reducers are noop, so I wouldn't expect the state to change as I'm not seeing anything that could change it!
As I'm getting it, you should probably add a new item to the array when reducing .addButtonPressed.

Also, I'm not sure that a computed property is the right tool for some computationally expensive task. You would probably want to keep this hard-earned data around in some way or another. The usual way to do this is to spawn a task that updates the sortedAppListItems once some relevant data has changed or some action is received.

As an aside, and in the general picture, you would probably want to scope the store of WithViewStore for AppListView to a smaller state than AppListReducer.State. Here, store.stateless would work, but WithViewStore(store.stateless) is usually an indication that you can create an on-demand ViewStore(store.stateless) to send the action directly in the closures.. In your case, it shouldn't be effectively problematic to observe the whole state as the enclosed view is really simple, but scoping [With]ViewStore's to a narrow ViewState is probably a good habit to take if you're not aware of it.

[kuglee]

Thanks for your answer!

I know that the state isn't updated, just wanted to show that the property is evaluated when there's no state change.

The appListItems would actually come from a parent reducer and it's unsorted. I thought if the list remains unchanged, it wouldn't be recomputed.
I don't really want to sort the list in the parent reducer, because later I would like to be able to change set the sort order in the AppListView.
Do I have to keep the list sorted in the model?

[tgrapperon]

Ah OK, sorry, I misread your example. Yes, the computed property is accessed because you're scoping a store using it. The scoped store you created in ForEachStore is observing the parent's state for mutations (through the lens of the computed property). However, in Swift, inout arguments are copy-in/copy-out most of the time. It means that if you have a function:

var string: String {
  didSet { print("didSet") }
}

func f(_ string: inout String) { print(string) }
f(&string) // will print "didSet"

The inout argument is extracted, and then reassigned at the end of f execution. The compiler is able to simplify the execution to avoid the reassignation if the state can't have changed, but only in very simple cases. This is likely not the case with the inout State of reducers, so when you send an action, the root store extracts a state to work on it, and will reassign it once the action is reduced. This in turn triggers your scoped store to pull out a new version. There is no diffing/comparison at this level, and it signals with the same sensitivity of a will/didSet observer.

So if the state has been assigned, the scoped child will extract a new value, and this (re)assignation systematically happens when the root store finishes reducing an action, whatever the outcome/changes. This explains why you're seeing your computed property being accessed.

Now, about your computed property: with TCA, nothing happens without being accountable. It means that if you change the sort order, or if the base array changes, you should be able to catch the responsible action in some reducer, and update the sorted array accordingly. So I would totally keep the list sorted in the model here, as rerenders and any actions being emitted are much more frequent than changes of sort order or items being added. This is usually not really problematic, and you can even think about creating a generalized wrapper that handles filtering/sorting. So you would have Parent>SortAndFilter>AppList, and AppList wouldn't need to be aware of the sorting if you want. Or you can perform more simply the sort in AppList and emit some "sort" action from a parent reducers (or whatever domains controls the sort order). It really depends on your app's organization. Feel free to post an example use case if you want more explicit indications.

[kuglee]

Thanks 🙏