Is it possible to specify the dependencies of a feature in a module/target without implementing them?

[ntbsp]

Hi folks 👋

Question

With ReducerProtocol and DependencyValues, is it possible to specify the dependencies of a module/target without implementing them?

Background

Our project is composed of multiple features, where each feature is a set of separate targets (via Tuist). For simplicity's sake, let's say there are three targets for each feature: Implementation, Tests, and Demo (live).

Currently, if we want to define dependencies on our feature reducer in the Implementation target, we are forced to implement the .testValue property (at a minimum) in the same Implementation target. Here's why:

1. Dependencies declared with the @Dependency property wrapper in the implementation of the feature's ReducerProtocol require that DependencyValues is extended with the same keypath in the same target.
2. In order to add a dependency to DependencyValues, the object used in the subscript operator must conform to TestDependencyKey.
3. In order to conform to TestDependencyKey, we need to add a testValue static property.

Ideally, we would only want "unimplemented" versions of our dependencies to be included in the Tests target, and "live" versions of our dependencies in the Demo target. But the way the API is structured, we are required to implement these in the Implementation target. Sometimes this is not possible because the Implementation target does not depend on the "unimplemented" versions of our dependencies.

Potential Solution

Implement an EmptyDependencyKey (insert better name here) protocol that does not require a value of the dependency to be implemented (i.e. only require the Type and KeyPath of the dependency). Given that, we could define features like so:

Feature Implementation/Interface Target

public struct MyDependencyKey: EmptyDependencyKey {}

extension DependencyValues {
    public var myDependency: MyDependency {
        get { self[MyDependencyKey.self] }
        set { self[MyDependencyKey.self] = newValue }
    }
}

Demo/Live Target

extension MyDependencyKey: DependencyKey {
    public static var liveValue: MyDependency = .init(...)
    public static var previewValue: MyDependency = .init(...)
}

Tests Target

extension MyDependencyKey: TestDependencyKey {
    public static var testValue: MyDependency = unimplemented(...)
}

Thanks for your time in advance 🙂

[stephencelis]

@ntbsp Can you explain more of your motivation behind wanting this separation? Test/unimplemented dependencies should be super lightweight, especially in release builds (most of that code is hidden behind #if DEBUG), so there should be no problem with that code being built everywhere. For most test/unimplemented dependencies, you can consider them as more of an interface than an implementation.

The only place where a dependency might be heavyweight is the live dependency, which could depend on a third party library that takes a long time to build, but the live dependency key conformance can live in its own module, that only the app target depends on.

Also note that unimplemented is useful beyond test targets, where they produce XCTest failures. When run from an app target, you'll see purple Xcode warnings emit whenever an unimplemented dependency is interacted with.

[ntbsp]

Thanks for the explanation! Our motivation for wanting this separation is largely related to our current strategy of implementing test/unimplemented dependencies.

For features, we encapsulate those dependencies in separate Mocks targets (which is only included as a dependency of Tests targets). For libraries, we hide the test/unimplemented dependencies behind an #if DEBUG like so:

// MARK: - failing

#if DEBUG
  extension Library {
    /// A `failing` version of the library
    public static func failing(
      method: () -> Int = unimplemented("\(Self.self).method")
    ) -> Self {...}
  }
#endif

We cannot use this in the implementation of a feature because it will be built for release. Of course, we can change our strategy for defining test/unimplemented dependencies by removing the #if DEBUG in libraries and move the dependencies in Mocks targets to the Implementation targets for features. But I am curious to know your thoughts first.

What is the motivation for using test/unimplemented dependencies for an interface instead of just listing the dependency types and keypaths? I would think that the type and keypath of a dependency is the only required information for the implementation of reducers. Thanks in advance for your help 🙂

[kamcma]

If I'm following (not a given!), I think this may simply be dependency management paradigm trade-offs. Because the new Dependencies module is kind of service-locator-pattern-y—that is, features will reach out to a global dictionary to ask for their dependency—it, as a deliberate part of its API design, requires you to provide at least one implementation so it is guaranteed there is something there for it to return.

If you don't love that, you can, as explained in the ReducerProtocol videos, eschew DependencyValues and @Dependency and keep using the pre-ReducerProtocol dependency management style. Though instead of an Environment type, you simply store dependency interfaces on your feature, and statically provide them via initialization.

[Alex293]

One can also inject the other DI framework resolver in TCA DI system so you can

@Dependencies(.myResolver) var resolver
and then use resolver.getMyDependency()

Thought TCA provides lots of value like scoping dependencies etc which you loose if you go out of it's way.