Controlling Dependencies of Dependencies

[pteasima]

In this tweet, pointfreeco have embraced using @Dependency in the dependency getter (e.g. liveValue), although they later discouraged overuse.

The example they give uses .envVars dependency synchronously to determine which DatabaseClient to return.

However, I would like to explore the possibily to use dependencies in other dependencies "later", inside their own behavior (think a .database dependency's .readTable endpoint uses .logger dependency to log the fetched data).

Below example summarizes current behavior. This is expected with the current implementation, but the notable part is how "a new .foo isn't available to .bar until after the changes are finished and after the .bar is reset to a new .liveValue in a nested withDependencies context.

The code is available in this gist.

Not only does the need for nested withDependencies calls affect ergonomics, but the required $0.bar = .liveValue reset overwrites any other changes that may have been made to other endpoints of Bar. With that, it seems like the pattern of using dependencies in other dependencies is currently not supported and should be discouraged. I have some ideas for potentially improving support for this pattern, but at this point Im unsure if thats even desirable, so I wonder what others have to say on the topic. Thanks in advance.

[mbrandonw]

This is happening because withDependencies is only wrapping the construction of the view, not the evaluation of the view's body. There would need to be some kind of deeper integration with the Dependencies library and SwiftUI to allow using in a SwiftUI view.

Also, the more I think about it, the more I think it may not be a good idea to use @Dependency inside SwiftUI views. It will be very easy to accidentally access a dependency from an escaping closure (such as a button action closure), which means you will lose all of the dependency overrides.

There may be a way to solve these problems, but it needs work to figure out.

[pteasima]

Oh, this is brilliant! Pardon my ignorance. I thought withDependencies(from: is some unimportant sugar, but here it actually solves a real problem.

So while it is probably still true that you can't do

withDependencies { 
   $0.envVars = .fakeEnvVars
   } operation: {
      MyModel()
   }

and get a database thats configured based on .fakeEnvVars, it does address some of my other concerns.

I'd be happy to close the discussion unless you feel something hasn't been addressed. Thanks as always!

[pteasima]

will still test the last bit and confirm

[pteasima]

🤯 I was wrong again, even that last example works exactly as I (didn't) descibe 😀 So basically for objects it does what you expect. Awesome!

Views are different and it was not designed for them.

[mbrandonw]

Yeah, the example you posted with the envVars and database should work, and in fact it's exactly what we do for the pointfree.co server code.

We will try to find time to think more about how dependencies could be propagated down to SwiftUI views. We've got a few other things that are a bit higher priority, but do let us know if you research it too. 🙂

[pteasima]

Im definitely bound to do that, given that I often use a "no architecture, put stuff in View" approach in codebases that don't strive for testability but do want to benefit from DI in previews.

I just need to measure twice before posting 🤦‍♂️😅. I would have never guessed that using Views matters here.

[pteasima]

Although most concerns were addressed in above thread. I found some strange behavior in the below example.

struct Foo: DependencyKey {
  static var liveValue: Self {
    .init {
      "foo"
    }
  }
  
  var foo: () -> String
}
extension DependencyValues {
  var foo: Foo {
    get { self[Foo.self] }
    set { self[Foo.self] = newValue }
  }
}

struct Bar: DependencyKey {
  static var liveValue: Self {
    @Dependency(\.foo) var foo
    return .init {
      return foo.foo()
    }
  }
  
  var bar: () -> String
}

extension DependencyValues {
  var bar: Bar {
    get { self[Bar.self] }
    set { self[Bar.self] = newValue }
  }
}

struct DependenciesPlayground_Previews: View, PreviewProvider {
  static var previews: some View {
    VStack {
      withDependencies {
        $0.foo.foo = { "baz" }
      } operation: {
        self.init(model: Model())
      }
    }
  }
  final class Model: ObservableObject {
    @Dependency(\.foo) var foo
    @Dependency(\.bar) var bar
    init() {
      _ = bar // include to get "baz", comment out to get "foo"
    }
  }
  
  init(model: Model) {
    _model = StateObject(wrappedValue: model)
  }
  @StateObject private var model: Model
  
  var body: some View {
    Text(model.bar.bar())
  }
}

I wouldn't expect that the act of resolving .bar in the model's initializer and doing nothing with it impacts the outcome. Will see if this potentially mattered in my original example.

[pteasima]

Turns out same "workaround" can be done for Views. I have no complaints about the following example, it resolves the reason I started this discussion. I get "baz" ✅. But, if I don't happen to touch bar in init (or otherwise synchronously), then I get "foo" ❌. This is tolerable already and could likely be abstracted with some new withDependencies sugar for views as you loosely suggested.

struct DependenciesPlayground_Previews: View, PreviewProvider {
  static var previews: some View {
    VStack {
      withDependencies {
        $0.foo.foo = { "baz" }
      } operation: {
        self.init()
      }
    }
  }
  @Dependency(\.foo) var foo
  @Dependency(\.bar) var bar

  init() {
    _ = bar
  }
  
  var body: some View {
    Text(bar.bar())
  }
}

[mbrandonw]

Ah yes, I think I spoke too soon when I said the dependencies library would work with @StateObject. The initializer for @StateObject takes an @escaping @autoclosure in order to be lazy, which means your model is actually created later, and hence does not see the overridden dependencies.

The reason everything works so nicely in our Standups app is because we use @ObservedObject everywhere, and have our features integrated together rather than islands of features like with @StateObject.

We technically do have a tool in the library specifically for escaping closures (it's called withEscapedDependencies, and it should work, but it does look gnarly.

You need your view initializer to take an escaping autoclosure so that it can be lazy, and then you need to propagate dependencies across the escaping boundary:

class Model: ObservableObject {
}

struct ChildView: View {
  @StateObject var model: Model

  init(model: @escaping @autoclosure () -> Model) {
    self._model = withEscapedDependencies { continuation in
      StateObject(
        wrappedValue: {
          continuation.yield {
            model()
          }
        }()
      )
    }
  }

  var body: some View {
    EmptyView()
  }
}

I didn't actually test this, but it should work unless there's something I'm overlooking.

[tgrapperon]

I have a dedicated property wrapper for the StateObject autoclosure issue in swift-dependencies-additions.
You simply replace @StateObject by @StateObject.Dependency and dependencies are eagerly captured and replayed to the ObservableObject when it is effectively created (which is the same as Brandon's solution).

[tgrapperon]

That being said, the only place where I would be comfortable to use @Dependency in View would be for previews. Otherwise, if I would need to push a dependency through the Views tree, I would make it an EnvironmentKey too and send it through the Environment (which is built to do this). You can even pull these dependencies from a model, pass them through the environment, and pop them out again to hydrate a new model far away (I'm not sure this is a good idea overall, but this is technically possible).