Using @Dependency inside State

[patch-benjamin]

I've run into issues where I want a variable on state to be different based on a Dependency passed in. The problem as I see it though is that @dependency is only guaranteed to be accurate if used inside the Reducer body/reduce variable/func and putting an @dependency in State will not work properly if called from a View (because usually you override the Dependency inside the Reducer body var).
Is there a good way to accomplish this? The best solution I can think of is to have a Action.viewDidAppear action that is called so the body var can update state based on the Dependency passed down the stack. I don't love that though because it's really easy to not do and easy to overlook when reviewing code. Is there a better way to do this? Maybe some way to force a Reducer.body to be called on init (kinda like how Subscribers sink get an initial call when subscribed before data is passed down)?

Example code of what I want to do:

State {
    var showNewNav: Bool {
        @Dependency(\.flags) var featureFlags 
        // DANGER: If `featureFlags` is overridden in the Reducer stack and a `View` calls this variable, 
        // the View will not get the reducer-overridden value, right? What is the best way to do this? 

        return featureFlags.enabled && featureFlags.showNewNav
    }
    ....
}

[kamcma]

If the computed property is only on your state so it can be read by the view, perhaps to display something conditionally, maybe it's more appropriate to be put in the @Environment? If it's on your state so it can be checked by reducer logic, just access the dependency there directly, rather than transitively through state that accesses the dependency.

Either way, as you acknowledge, accessing the dependency in a computed property on state doesn't feel quite right to me, because it makes your state not-inert.

[mbrandonw]

The best solution I can think of is to have a Action.viewDidAppear action that is called so the body var can update state based on the Dependency passed down the stack

There's another option. You can use @Dependency in the initializer of your state rather than accessing it in the computed property. State is always created inside a reducer, and therefore it is covered by the cascading rules of withDependencies:

struct State {
  var showNewNav: Bool

  init() {
    @Dependency(\.flags) var featureFlags
    self.showNewNav = featureFlags.enabled && featureFlags.showNewNav
  }
}

[patch-benjamin]

Yaaaasssss! This is exactly what I was looking for! ❤️

[rod-schmidt-cricut]

Would that be same for ViewState or since that is derived from normal state you can just derive your view state from the full reducer state?

[patch-benjamin]

Rod's on my team:) For code context he's talking about something like this:

struct TestView: View {
    struct ViewState: Equatable {
        var someVariable: String
        
        init(_ state: ParentReducer.State) {
            @Dependency(\.featureFlags) var featureFlags
            if featureFlags.contains("someFlag") {
                someVariable = state.newFeatureVariable
            } else {
                someVariable = state.oldFeatureVariable
            }
            
        }
    }
    
    let state: StateOf<ParentReducer>

    var body: some View {
        WithViewStore(store.scope(state: ViewState.init)) { viewStore in
            
            /// view stuff
            
        }
    }
}

So I guess the question boils down to, is store.scope(state: (State) -> ChildState)) also called/created inside a reducer or will we need to pull the @Dependency used in the ViewState.init up into the ParentReducer.State.init to get it working properly?

[mbrandonw]

No, this technique will not work on view state because that is evaluated in the view, and dependencies are not propagated to views. The technique only works in the reducer's state.