Using Dependencies in a Modular project Gotcha

[HugoSay]

Using swift-dependencies in a modular architecture, the recommended method for defining a Key without its definition is to use the TestDependencyKey Protocol.

There is a gotcha using this method, though:

When declaring the testValue of a dependency using TestDependencyKey in a Module A. If you try to declare a different previewValue alongside the liveValue implementation in your DependencyKey implementation in module B. The testValue from module A will be used as a previewValue regardless.

What could be done about it ?

• Documenting this in the TestDependencyKey protocol, the previewValue of the DependencyKey protocol or somewhere in the readme ?
• I tried removing the previewValue requirement from the TestDependencyKey protocol and replacing it with the same method that was used to access the live value and it worked as expected.

{
      case .live:
        value = _liveValue(key) as? Key.Value
      case .preview:
          value = _previewValue(key) as? Key.Value
      case .test:
        value = Key.testValue
      }

Still, I'm not sure this is the correct answer in terms of ease of use. Now that I had time to think about it, the idea of specifying a previewValue alongside the liveValue instead of the testValue in a modular architecture makes less sense than I originally thought.

• Should the TestDependencyKey be divided into 3 definitions ? TestDependencyKey, PreviewDependencyKey and a TestAndPreviewDependencyKey that would combine them both ?

Here is a sample kindly provided by @tgrapperon that helped me look into the issue 😊
DependencyPreview.zip

[mbrandonw]

Yeah this does seem like a gotcha, but also I don't think it's a bug. I think this is the intended behavior as far as Swift is concerned. You aren't allowed to extend a protocol with default implementations from another module.

I will look into improving the documentation, but I don't think there's really anything we should do in the library itself. Adding even more protocols is too heavyweight, and I think by far the most common use case is to define the testValue and previewValue in the same module. The previewValue should be super lightweight to compile, and so there should be no need to move it to the implementation module.

Can you explain a bit more why you wanted to define the previewValue in the implementation module?

[HugoSay]

Hey, Thanks for your answer. I completely agree that it's a gotcha, not a library bug.

A use case for defining the previewValue in the implementation module would be to create previews in the implementation module itself without having to use withDependencies on the preview call.

I think what took me by surprise is the DependencyKey previewValue documentation:

 /// A default implementation that provides the ``liveValue`` to Xcode previews.
  ///
  /// You may provide your own default `previewValue` in your conformance to ``TestDependencyKey``,
  /// which will take precedence over this implementation.
  public static var previewValue: Value { Self.liveValue }

I figured it would work between modules as well. It makes sense that it doesn't after all :D

[mbrandonw]

A use case for defining the previewValue in the implementation module would be to create previews in the implementation module itself without having to use withDependencies on the preview call.

If I'm understanding correctly, if you had your previewValue defined in the interface module and you created a SwiftUI preview in your implementation module, then I would expect the previewValue to be used. Is that not the case?

I think what took me by surprise is the DependencyKey previewValue documentation:

Ah I see, that looks like a good place to update to mention this gotcha, as well as a few other spots. Thanks!

[HugoSay]

If I'm understanding correctly, if you had your previewValue defined in the interface module and you created a SwiftUI preview in your implementation module, then I would expect the previewValue to be used. Is that not the case?

It's the opposite -> If I don't define a previewValue in my interface module and define one in the implementation module. I'd expect my previews from the implementation module to use the previewValue from the implementation module. But it's not the case currently.

I'd even say that only defining a liveValue in my implementation module, I'd expect it to be prioritized over the testValue of the interface module in the implementation module itself.

Here is the current behavior:

// Interface module
public enum MyDependencyKey: TestDependencyKey {
    public static var testValue: MyDependency = MyDependency(test: unimplemented("test1", placeholder: "unimplemented placeholder"))
}

// Implementation Module
extension MyDependency: DependencyKey {
    public static var liveValue: MyDependency = MyDependency(test: "live value")
    public static var previewValue: MyDependency = MyDependency(test: "Preview Value")
}

public struct DependencyView: View {
    @Dependency(\.dependency.test) var testPreviewValue
    public var body: some View {
        Text(testPreviewValue) //  displays -> "unimplemented placeholder"
    }
}

[tgrapperon]

Hey @HugoSay! The whole TestDependencyKey/DependencyKey dichotomy was justified by the idea that live value may be sometimes quite lengthy to build, and that you may want to only build the liveValue when it's really needed (i.e. when you're building the full app). In other words, if you define the DependencyKey in its own module, then the only thing you can do is define a liveValue. Everything else (including the complete dependency model) should ultimately go in the module where the TestDependencyKey is defined. This is enforced by the way Swift works, and there is no real way around it, besides manually assigning some dependency value that can live in the "implementation" module when writing SwiftUI previews.

I understand that you understood that, but I'm wondering what leads you to want to define the previewValue alongside liveValue then. I can imagine that you may consider previewValue being partly implementation stuff in the "interface/implementation" scheme, so maybe one solution would be to rethink this more as a "debug/release" or "develop/build" idea.