Controlled dependencies in TestStore.send state updates.

[crayment]

Describing the problem

Working on adopting ReducerProtocol and have a question about a pattern we have been using. We often use the current environment in our state initializers. Something like this:

struct SomeFeature: ReducerProtocol {
    struct State: Equatable {
        var date: Date
        
        init() {
            self.date = DependencyValues._current.date()
        }
    }
    
    enum Action {}
    
    func reduce(into state: inout State, action: Action) -> EffectTask<Action> {}
}

This works fine but becomes a bit frustrating when testing since we need to control dependencies before the store is created

func testSomeFeature() {
    let store = TestStore(
        initialState: SomeFeature.State(), // Dependencies not controlled here, test fails
        reducer: SomeFeature()
    )
    store.dependencies.date = .constant(.init(timeIntervalSinceReferenceDate: 1337)) // Too late for State.init
}

And there is a similar issue when sending actions to the test store. Say there is a parent feature that optionally presents the one from above:

struct ParentFeature: ReducerProtocol {
    struct State: Equatable {
        var child: SomeFeature.State?
    }
    
    enum Action {
        case tap
        case child(SomeFeature.Action)
    }
    
    var body: some ReducerProtocol<State, Action> {
        Reduce { state, action in
            switch action {
            case .tap:
                state.child = SomeFeature.State()
                return .none
                
            case .child:
                return .none
            }
        }
        .ifLet(\.child, action: /Action.child) {
            SomeFeature()
        }
    }
}

When we try to test the parent's action that creates the child state we run into the same issue:

func testParent() {
    let store = TestStore(
        initialState: ParentFeature.State(),
        reducer: ParentFeature()
    )
    store.dependencies.date = .constant(.init(timeIntervalSinceReferenceDate: 1337))
    
    store.send(.tap) {
        $0.child = .init() // Doesn't use controlled dependency, but the reducer under test does. So we fail with the wrong date!
    }
}

Alternatives & Reasoning

You may be tempted to simply wait until a task or onAppear effect fires to setup this state. But this isn't ideal because the view needs to render once with a default value, fire its event, then immediately update with the new value. We have seen display glitches when forcing the view to update so quickly after being created, and it's also a bit wasteful. It also forces you to have a default value or make the state optional. Neither of which are ideal.

Another alternative would be to simply pass the date into the init. This pushes the responsibility to the parent and comes with the problem of dependency injection cascading many levels of parent hierarchy unnecessarily.

You could also have two versions of the init. One that is used by parent reducers and another that is used by the tests. Then the tests would be able to specify the exact value they want. This is a bit annoying because Swift doesn't generate a default initializer when you implement one like I have above. So you have to implement a whole new init just for test code.

Proposed Solution

I would love to get thoughts on making the updateExpectingResult argument on TestStore.send be called with the dependencies from the store. As well I think you could make TestStore.init use @autoclosure for the initialState argument and accept either DependencyValues directly, or a closure for configuring them.

I have solved this for myself with the following extensions which allow dependencies to be controlled for both the TestStore.init and testStore.send state update.

public extension TestStore {
    static func create<Reducer: ReducerProtocol>(
        initialState: @autoclosure () -> State,
        reducer: Reducer,
        dependencyUpdates: (inout DependencyValues) -> Void,
        file: StaticString = #file,
        line: UInt = #line
    ) -> TestStore<State, Action, State, Action, Void>
        where
        Reducer.State == State,
        Reducer.Action == Action,
        State == ScopedState,
        Action == ScopedAction,
        Environment == Void
    {
        var dependencies = DependencyValues()
        dependencies.context = .test
        dependencyUpdates(&dependencies)
        return DependencyValues.$_current.withValue(dependencies) {
            let store = TestStore(initialState: initialState(), reducer: reducer, file: file, line: line)
            store.dependencies = dependencies
            return store
        }
    }
}

public extension TestStore where ScopedState: Equatable {
    @MainActor
    @discardableResult
    func sendWithDependencies(
        _ action: ScopedAction,
        _ updateExpectingResult: ((inout ScopedState) throws -> Void)? = nil,
        file: StaticString = #file,
        line: UInt = #line
    ) async -> TestStoreTask {
        await send(
            action,
            { state in
                try DependencyValues.$_current.withValue(self.dependencies) {
                    try updateExpectingResult?(&state)
                }
            },
            file: file,
            line: line
        )
    }
}

Usage. Tests now both pass!

func testChild() {
    let store = TestStore.create(
        initialState: SomeFeature.State(),
        reducer: SomeFeature()
    ) {
        $0.date = .constant(.init(timeIntervalSinceReferenceDate: 1337))
    }
}

func testParent() async {
    let store = TestStore.create(
        initialState: ParentFeature.State(),
        reducer: ParentFeature()
    ) {
        $0.date = .constant(.init(timeIntervalSinceReferenceDate: 1337))
    }
    
    await store.sendWithDependencies(.tap) {
        $0.child = .init()
    }
}

[mbrandonw]

Hey @crayment, this is a very good suggestion! I just opened a PR with this functionality: #1620

[lukeredpath]

Personally, I feel like having hardcoded use of dependencies inside your state structs is causing strong coupling and is unnecessary. I think you should just be passing in the values you need to the initialiser. I don't see how this creates a cascading parent dependency injection issue, because the reducer that initialises the state can still use @Dependency to get access to what it needs, e.g.:

struct Parent: ReducerProtocol {
  @Dependency(\.date) var date

  func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
    switch action {
      case .initChild:
        state.child = Child(date: date())
    }
  }
}

To me this is much clearer than having hidden dependencies inside the initialisers of your value types. It also makes initialising your state with a specific value in your tests trivial without having to jump through hoops to configure your dependencies.

[mbrandonw]

I tend to agree with @lukeredpath and nearly posted as much, however we feel that the change to TestStore is a good one regardless.

The main reason we recommend against using dependencies directly in a state initializer is because it makes tests slightly weaker than they could be. We briefly talk about this in our testing article, but as a simple example, one could test a counter reducer like this:

await store.send(.incrementButtonTapped) {
  $0.count += 1
}
await store.send(.decrementButtonTapped) {
  $0.count -= 1
}

That will pass, but it's not as strong as it could be. We are only proving that state went up or down by one, but not that we know the exact value of state. So, this is a bit stronger:

await store.send(.incrementButtonTapped) {
  $0.count = 1
}
await store.send(.decrementButtonTapped) {
  $0.count = 0
}

This is similar to @crayment's original test to. Rather than doing this:

store.dependencies.date = .constant(.init(timeIntervalSinceReferenceDate: 1337))
    
store.send(.tap) {
  $0.child = .init()
}

…we think it makes for a stronger test to do this:

store.dependencies.date = .constant(.init(timeIntervalSinceReferenceDate: 1337))
    
store.send(.tap) {
  $0.child = .init(date: .init(timeIntervalSinceReferenceDate: 1337)
}

[crayment]

I appreciate the feedback! Happy I created this conversation as it's already leading to smoother path to adopting ReducerProtocol for us.

I guess I was thinking of the init as being part of the child domain, but if you think of initializing the child as part of the parent domain then it makes sense that the parent is the one that needs that dependency.

And you are right the dependency doesn't cascade upward beyond the parent once everything is converted. We had this pattern already established, using our own global environment solution to avoid the cascading problem prior to ReducerProtocol. Was trying to minimize the number of changes needed for adoption, but this init injection makes sense and there are slight changes I can make to our adoption strategy so we end up with this in the end!

[crayment]

Actually there are cases where this still will cause cascading for us. We have cases where the child state isn't optional and needs to be created in the parents init. So we are forced to cascade the dependency up another level. Maybe this is desired but you can end up having to pass a dependency into an init because it is used multiple layers of features below.

[mbrandonw]

I may need to see more code to fully understand, but it seems even if you have multiple levels of state to create that you would be able to do something like this from the parent domain:

case .buttonTapped:
  state.child = Child.State(
    grandchild: GrandChild.State(
      date: self.date.now
    )
  )

That is, no need to pass dependencies down and instead just invoke the dependencies from the parent to create the child states.

[crayment]

I'll try to describe one of our use cases more specifically. We have a notification button that displays an unread count. The button is badged. We also have a feature setting that controls how it is displayed. Explaining why would is overly domain specific but just pretend there is some user-controllable setting stored elsewhere that influences the way the button needs to present and behave.

The button is displayed by many parents. We have tabs and on each tab we put it in a toolbar. On iPad the empty default views will also show it. It actually has 13 parents in our codebase.

Today the state has an init something like this:

struct State: Equatable {
  var featureSetting: NotificationFeatureSetting
  
  init() {
    @Dependency(\.features) private var features
    featureSetting = features.current().notificationsSetting // Reads current setting from cache or possibly load from disk. We want this known at `init` to avoid flashing the wrong version
  }
}

This means each of the many parents can instantiate it without the dependency cascading:

struct Parent: Equatable {
  var notificationButton: NotificationButton.State
  init() {
    notificationsButton = .init()
  }
}

If we were to inject the feature setting instead it would cascade up many branching levels of hierarchy.

struct TabA: Equatable {
  var someFeature: SomeFeature.State
  init(notificationsFeatureSetting: NotificationFeatureSetting) { // Have to take it in here so that we can construct our children
    someFeature = .init(notificationsFeatureSetting: NotificationFeatureSetting) // Have to pass it along here, even if there are many layers until the actual button is created.
  }
}

struct TabB: Equatable {
  var someFeature: SomeFeature.State
  init(notificationsFeatureSetting: NotificationFeatureSetting) { // Have to take it in here so that we can construct our children
    someFeature = .init(notificationsFeatureSetting: NotificationFeatureSetting) // Have to pass it along here, even if there are many layers until the actual button is created.
  }
}

The path you suggest would be to take in the grand children's state in the init directly, rather than the dependencies needed to instkantation them. It's probably better here but still leads to knowledge cascading up many layers and some really big ugly state initialization.

[rcarver]

I've got a similar-ish situation for describing whether the user has the "pro" level or "limited" version of the app.

• Parent domain uses a dependency client to observe the current upgrade state
• Parent initializes children with the current upgrade state, or pieces of it ("feature A is unlocked") and children pass it along to grandchildren as necessary
• If parent receives a new upgrade state it needs to push that to children, grandchildren, etc
• A Child can trigger an upgrade flow which changes the upgrade state locally, ensuring that it has the correct state immediately

This all works great, but it can feel like a lot of boilerplate keeping that state in sync. Each child could observe the state itself, but that's also a lot of boilerplate and opens up this "nil / default value" issue you're describing.

I've been wishing for for some kind of tree-local @Environment-like store that children could draw from to pluck out the state they need. It's easy enough to start sketching this out, basically copying how @Dependency works but the key difference is that a new value should write to the child's state such that its equality changes.

Here's a sketch of what it might look like. Lots of open questions, for starters is it read-only or read-write? Could Dependency be used here or is this really something different? If it's something new, what's a good name?

public struct ParentFeature: ReducerProtocol {
    public struct State: Equatable {
        var counter: Int = 0
        var child = ChildFeature.State()
    }
    public enum Action: Equatable {
        case increment
        case child(ChildFeature.Action)
    }
    public init() {}
    public var body: some ReducerProtocol<State, Action> {
        // ✅ Push some value from parent to any child that's interested in it
        Share(state: \.counter, to: CounterKey.self) {
            Scope(state: \.child, action: /Action.child) {
                ChildFeature()
            }
        }
    }
}
public struct ChildFeature: ReducerProtocol {
    public struct State: Equatable {
        // ✅ This would be initialized with the currently shared state or a default,
        // and if a new value is pushed to the key, this value would automatically be updated
        @SharedState(\.counter) var counter
    }
    ... 
}

[Alex293]

Interesting idea, this could bring back some data that is pushed to the environment because it’s used in a lot of place while being inconvenient to pass up / down to each feature like a userid.

[stephencelis]

@rcarver This definitely sounds interesting! If you come up with anything, please do share, maybe in a new discussion so it doesn't get buried here.

[rcarver]

Thanks @stephencelis will do!