MacOS windows with unique data

[nashysolutions]

The tutorial series located here at Apple explains that the following feature can be achieved by manipulating the model from within the view.

Different Filters in Each Window

Would this be easy to achieve using the composable architecture?

The reason I ask is because Apple recommend using a computed property on the view itself and you guys modify state within dedicated stores.

struct LandmarkList: View {
    @EnvironmentObject var modelData: ModelData

    .../

    var filteredLandmarks: [Landmark] {
        modelData.landmarks.filter { landmark in
            (!showFavoritesOnly || landmark.isFavorite)
                && (filter == .all || filter.rawValue == landmark.category.rawValue)
        }
    }

    .../

The above computed property is within the view, so when a new instance of this view is created, the output of this property will be unique for each view instance. The data remains in sync when you toggle the isFavorite start button.

Apple Sample Code - see folder named 'complete'
CreatingAmacOSApp.zip

[tgrapperon]

Hello @nashysolutions!
Yes, this is achievable: with TCA, the role of EnvironmentObject on the View's side is played by ViewStore. ViewStore exposes a State value that is generally equatable. Let's say for simplicity that this is the same LandmarkListState as your Store. You have two options:

• Declare the computed property in LandmarkListState, using self instead of modelData. You can then access this property from the ViewStore instance you have.
• Declare the computed property in the View, but use viewStore instead of modelData. For this to work, your ViewStore instance need to be stored in the View like it is the case for EnvironmentObject. This is not what happens when using WithViewStore. If you want to declare the computed property in the View, you need to create a self.viewStore = ViewStore(store: store) in the Views initializer, and have an @ObservedObject var viewStore: ViewStore<State, Action> property in your View:

struct LandmarkList: View {
  let store: Store<State, Action>
  @ObservedObject var viewStore: ViewStore<State, Action>
  init(store: Store<State, Action>) {
    self.store = store
    self.viewStore = ViewStore(store)
  }
  
  var filteredLandmarks: [Landmark] {
    viewStore.landmarks.filter { landmark in
      (!viewStore.showFavoritesOnly || landmark.isFavorite)
        && (viewStore.filter == .all || viewStore.filter.rawValue == landmark.category.rawValue)
    }
  }
  …
}

filteredLandmarks being a computed property is merely a convenience: it doesn't play any role in SwiftUI Views invalidation and it doesn't implement any protocol. If you go the computed property route, I would recommend to install it in your LandmarkListState, as you already store showFavoritesOnly and filter there when using TCA, instead of using @State properties in LandmarkList:

extension LandmarkListState {
  var filteredLandmarks: [Landmark] {
    self.landmarks.filter { landmark in
      (!self.showFavoritesOnly || landmark.isFavorite)
       && (self.filter == .all || self.filter.rawValue == landmark.category.rawValue)
    }
  }
}

Note that the toolbar button's state and action are controlled by LandmarkCommands.
(This is not true, only the menu is. The remark that follows still stands but it doesn't concern the toolbar's button in this case.)
In TCA, you would make this type host a Store instance, but you will need to use the manual @ObservedObject route, as WithViewStore is only accessible from View or Scene with the current version of TCA. I'll check if TCA can provide a WithViewStore that works in Commands or other similar protocols, and I'll PR if it does.

[tgrapperon]

As an aside, when using TCA, you can also store the filteredLandmarks and recompute them when needed: you create a .filterLandmarks action that assigns the filteredLandmarks to their storage in LandmarkListState, and you send this action as an effect (Effect(value: .filterLandmarks)) each time you receive another action that modify one of the parameters, for example an hypothetical .binding(.set(\.$showFavoritesOnly, _)) binding action. With TCA, no change happens without going through a reducer, so you can most of the time spot actions that triggers them and invalidate the model accordingly.

You can also use an higher order reducer like this one to observe them and recompute filtered items:

Reducer<LandmarkListState, LandmarkListAction, LandmarkListEnvironment> { 
  state, action, environment in
  switch action {
  case .filterLandmarks:
    state.filteredLandmarks = …
    return .none
  …
  }
…
}
.onChange(\.landmarks) { _, _, _, _ in Effect(.filterLandmarks) }
.onChange(\.showFavoritesOnly) { _, _, _, _ in Effect(.filterLandmarks) }
.onChange(\.filter) { _, _, _, _ in Effect(.filterLandmarks) }

Furthermore, if you have many items, filtering may take some noticeable time, and you may want to perform filtering in the background.