Using StoreOf<ReducerProtocol> in @Dependency(\.coreDependency.store) var store

[tunchamroeun]

Question

Is it ok to use StoreOf<ReducerProtocol> in eg. @Dependency(\.coreDependency.store) var store without passing StoreOf<ReducerProtocol> to View every time?

Using in my View

    /// MARK: - Environments
    ///
    @Dependency(\.coreDependency.store) var store
    /// MARK: ViewStore
    ///

    @ObservedObject var viewStore: ViewStore<ViewState, PaymentFeature.Action>
    init() {
        viewStore = .init(self._store.wrappedValue.scope(state: \.subscriptionState, action: CoreFeature.Action.subscriptionAction).scope(state: \.paymentState, action: SubscriptionFeature.Action.paymentAction), observe: ViewState.init)
    }

    struct ViewState: Equatable {
        let input: CreatePaymentInput
        let isValid: Bool
        init(state: PaymentFeature.State) {
            input = state.createInput
            isValid = state.isValidCreate
        }
    }

[tgrapperon]

Passing stores in dependencies is not something both types were designed for, and I'm almost certain that it will subtlety break things somewhere, and I wouldn't advice to do so. Furthermore, Dependency is not built to work in View, and this is another source of issues that are hard to debug. The "proper" property wrapper to use in View for a similar function would be @Environment. If you insist in going the "store from environment/dependencies" route, you can create an EnvironmentKey to pass your root store in SwiftUI's Environment. You can then pop this store out from the parent view, and scope it to pass a fully fledged store to your View's init like it is commonly done. This should likely work without surprises if the store is the root store, and it can maybe be some interesting idea to explore.

The fact that that you don't have a store at hand to scope from the parent view is a little suspicious, and I don't know if you're not fighting the architecture, if you're in the process of converting a vanilla app to TCA, or if you're in a totally legit situation.

As an alternative, and if your domain calls for reusability, you can maybe pass the ViewStore as a SwiftUI @EnvironmentObject:

@EnvironmentObject var viewStore: ViewStore<PaymentState, PaymentAction>
init() {}
var body: some View { … }

You would need to extract and inject a ViewStore of this shape near the root. Of course, it doesn't work in all domains, but this can be an alternative for autonomous features.

[tunchamroeun]

Thanks for your explanation to make clear about this!

[tunchamroeun]

@tgrapperon If I am correct, Dependency here is singleton right?

[tgrapperon]

Not exactly. Dependency is a tool that allows you to extract values from the current DependencyValues which is itself like a singleton but that can change temporarily. Like ViewStore is a tool that allows you to extract state from a Store.
You can imagine DependencyValues as a singleton if you want. It will not exactly behave like one (because you can override temporarily its values down a branch of models/stores), but there is always a current value of DependencyValues floating around that @Dependency can catch to extract the dependency you're looking for.
Note how this common value is named current¹ and not shared. Because this is not a singleton, there are many cases where it will break your expectations if you're using @Dependency in a View, but fortunately, SwiftUI comes with a tool that does more or less the same thing, but at the pace of View invalidation. I wouldn't mix the two by default though, and having to do so will likely be a red'ish flag.
So to sum up, Dependency is a property wrapper that allows to extract values from a kind of super-powered singleton that can change temporarily in a branch of reducers.
Let me know if I wasn't clear.

Footnotes

1. More exactly _current, but you don't need to access this internal value directly, @Dependency does this for you. ↩

[tunchamroeun]

Thank you so much. It is much clear.