Enabling Conformance to TestDependencyKey via @DependencyClient

[Ryu0118]

Hi, I would like to propose the feature of enabling conformance to TestDependencyKey via @DependencyClient.
I think why the macro doesn't generate conformance to TestDependencyKey is that if an extension for TestDependencyKey conformance already exists, it could lead to a compilation error.
However, what if we could choose whether to conform to TestDependencyKey via the macro parameter, or by creating another macro for this purpose?

@DependencyClient(testValue: .unimplemented, previewValue: .unimplemented)
struct Client {/* ... */}

+ extension Client: TestDependencyKey {
+    static let testValue = Self()
+    static let previewValue = Self()
+ }

In most cases, the testValue is implemented as 'unimplemented' for all endpoints, so making this aspect more convenient would be beneficial I think.

[stephencelis]

@Ryu0118 This is definitely a cool idea, and configuration aside I could see it being nice to extend @DependencyClients with TestDependencyKey by default.

However, because DependenciesMacros does not depend on the Dependencies module, I think we're OK requiring the user do this bit of extra work, especially because the extension is just one step in a multi-step process: DependencyValues would still needs to be manually updated.

Thanks for sharing the idea, though! We'll keep it in mind as these APIs evolve 😄

[andriyslyusar]

We can maybe implement DependencyValues similar to this environment value macro https://github.com/Wouter01/SwiftUI-Macros. Stephen, how do you think should we make a separate @DependencyValue macro or integrate the logic as part of @DependencyClients?

[mbrandonw]

Hi @andriyslyusar, there was a previous discussion about using macros to register dependencies here: #116

At the end of the day we don't think a macro really saves that much in this situation. It's only a couple of lines of code that need to be done for each dependency registered.

In contrast, our @DependencyClient macro can save hundreds of lines of code for a single dependency, and as the dependency gets more complex, the savings are bigger. The same isn't true of a theoretical @DependencyKey macro, and so we're not sure it's worth it.

However, if you or anyone else wants to experiment with the idea and share their findings we are definitely interested in learning more!