WindowGroup and Store

[kamcma]

Apologies, this is perhaps more a SwiftUI question than a TCA question, but maybe not. Here is a small demo counter SwiftUI app to illustrate my question:

import ComposableArchitecture
import SwiftUI

let counterReducer = Reducer<Int, CounterAction, Void> { state, action, _ in
    switch action {
    case .increment:
        state += 1
        return .none
    case .decrement:
        state -= 1
        return .none
    }
}

enum CounterAction {
    case increment
    case decrement
}

struct CounterView: View {
    let store: Store<Int, CounterAction>

    var body: some View {
        WithViewStore(store) { viewStore in
            HStack {
                Button("-") { viewStore.send(.decrement) }
                Text("\(viewStore.state)")
                Button("+") { viewStore.send(.increment) }
            }
        }
    }
}

@main
struct TestApp: App {
    var body: some Scene {
        WindowGroup {
            CounterView(
                store: Store(
                    initialState: 0,
                    reducer: counterReducer,
                    environment: ()
                )
            )
        }
    }
}

If you run this application on macOS and hit ⌘-N a few times to open new windows, the counters will all move in sync, as if they share a single Store. This is somewhat counterintuitive to me, because it seems like each instance of the root view should instantiate its own Store.

The WindowGroup documentation states:

Every window created from the group maintains independent state. For example, for each new window created from the group the system allocates new storage for any State or StateObject variables instantiated by the scene’s view hierarchy.

That seems to hint that whatever view is acting as the WindowGroup root must hold its state in @State or @StateObject property wrappers for the WindowGroup to track them distinctly. A discussion on the Swift Forums observed this as well.

My first through was to apply an @StateObject property wrapper to the Store property in the root view, but alas Store does does not conformed to ObservableObject as @StateObject requires. My next thought is to hold on to my root state directly in the root view with an @State property wrapper and then pass that into a Store, but I worry that's not correct because I don't see how the Store would ever communicate mutations back out to the @State property.

Perhaps one should hold on to an array of state values up at the App level? But then I'm not sure how you hook into the WindowGroup to ForEach on them, listen for new windows, etc.

(Perhaps I should qualify that I have a very simple use case, and I want to allow multiple windows on macOS, but I want them to function as basically totally independent instances of the app. Hence why I am after this un-synchronized state behavior.)

Does anyone have any thoughts on this? Am I missing something obvious? Thank you in advance. 🙂

[kamcma]

Part of me thinks trying to get WindowGroup windows to have independent state is fighting the WindowGroup model (eg, if you open two Mail.app Viewer Windows, you're clearly seeing the same domain state, if not the same view state), except that the documentation is so explicit that independent states are supported, if you'll use the right property wrappers. Feels like there should be a more manual fallback to achieve that behavior without the property wrappers.

[kamcma]

So, it seems like I can get the behavior I'm after if I conditionally conform my root Store to ObservableObject so I can use the @StateObject property wrapper on it in the root view.

extension Store: ObservableObject where State == MyRootState, Action == MyRootAction {}

struct RootView: View {
  @StateObject var store: Store<MyRootState, MyRootAction> = Store(/* ... */)

  // ...
}

I doesn't matter that I don't add any @Published properties to the Store, because that's not how we interact with Stores anyway.

Is there a downside to this I am not seeing? It seems like the @State and @StateObject property wrappers are the only way to flag to WindowGroup that you want all the windows to have distinct state.

[lightandshadow68]

I think what you want is DocumentGroup. However, document apps are expected to serialize their data from and to disk via a file wrapper. If you can make your state Codable, you could add actions for encoding and decoding your state to and from Data.