should AppEnvironment contain all dependencies from all subvEnvironments?

[ivangodfather]

Lets say we have View that creates a new Store (deep in the hierarchy). Should the AppEnvironment contain this dependency and pass it along the way? Lets say we need UserDefaults, { ListEnvironment(dependency: $0.userDefaults }, then { DetailEnvironment(depenceny: $0.userDefaults }. Or could we pass the dependency once we create the DetailEnvironment ?
Or its a preference? I saw in https://www.raywenderlich.com/24550178-getting-started-with-the-composable-architecture#toc-anchor-015 they ignore the previous environment but in some examples of TCA they are passing all the way along from AppEnvironment

[lukeredpath]

Generally, you should hold on to all of your app's dependencies in the root AppEnvironment and pass them down the hierarchy to the child domains that need them.

If you don't do this, you can make it harder to control your environment in tests - for example, whilst you can always directly test any feature domain and inject your dependencies using a TestStore, there are sometimes cases where you need to test a feature domain's integration into a parent domain - when you do this you only have control over the parent domain's environment and not the direct child environment, as this would be created by the pullback that integrates the child reducer into your parent.

For example:

struct ParentFeature {
  var child: ChildFeature
}

enum ParentAction {
  case child(ChildAction)
}

struct ParentEnvironment {
  var foo: FooClient
}

let fooReducer = Reducer<...>.combine(
  childReducer.pullback(
    state: \.child,
    action: /ParentAction.child,
    environment: { _ in ChildEnvironment(bar: BarClient()) }
  )
)

// child domain omitted

If you want to write some tests for this feature that also exercise parts of the child domain, you have no way of controlling child feature's dependencies because the child environment is hardcoded to use BarClient().

If instead ParentEnvironment had a BarClient that it could pass into the child, you would be able to fully control this dependency when you configure your TestStore environment in your tests and that test dependency will get injected into the child environment.

[stephencelis]

@lukeredpath is totally right, though you can use @tgrapperon's library to simplify the boilerplate of dependency passing. We've also been working towards a model that will simplify this (which both Luke and Thomas have some experience with). It's not quite ready yet, but we're hoping to refine it for production in the coming months.

[lukeredpath]

Yes, it's 🔥 - can't wait.

[clayellis-cricut]

Any updates on this new model?

[stephencelis]

@clayellis-cricut It's next on the list after concurrency!