Some opinion & question after trying this library

[HotFryingPan]

Hi @stephencelis @mbrandonw,
Before starting, thanks for making this lib and I'm sorry if Discussion is not the appropriate place to share about this. Please let me know & I'll move the discussion to the appropriate place 🙇

I was jumping & trying to migrate my app to use this library for a while and I want to share what I found, feel, and concerns after migrating to this lib:

1. This lib is more like a service locator.
2. Everything always need default value which is not my cup of tea.

• I'm not sure what's the reason behind this idea. But could be better if we can interchangeable between creating new object & shared object.
• This behavior feels like this lib is very opinionated to 1 approach & not flexible.

3. My build is slower because we must implement testValue inside the DependencyKey or TestDependencyKey. ( I put the code below for example of what I did)

• The code also build the Mock classes. I'm aware it's lightweight, but if we have many mock classes in the entire project, the time adds up. It's better to not compile it at all.
• I think this is the limitation of the current protocol conformances. Can we think of another way to achieve this?
• I'm not sure if this is known issue/not. But IMO this is a big issue & deal breaker for me to adopt this lib further. Please let me know if we can have a workaround to solve this.

Here's my old code using simple constructor injection

#### Inside Source Target
protocol SomeUseCase { // Any random dependency
  func newMethod()
}

struct SomeObject {
  init(useCase: SomeUseCase) { // use the dependency here without any default value
    ...
  }
}

#### Inside Test Target
class MockSomeUseCase { // Only compiled when building the test
  func newMethod() { 
  ... // do what my mock's caller needs
  }
}

And here's after using this library

#### Inside Source Target
private enum SomeUseCaseKey: DependencyKey {
  static let liveValue = SomeUseCaseImpl()
  static let testValue = MockSomeUseCase()  // Because of this, we can't put the mock inside Test Target
}

struct SomeObject { 
  @Dependency(\.someUseCase) var useCase: SomeUseCase
}

class MockSomeUseCase { // Must be included in the Source target
  func newMethod() { 
  ... // do what my mock's caller needs
  }
}

[mbrandonw]

Hi @HotFryingPan, I have some answers to you questions below:

This lib is more like a service locator.

Is this a concern? We feel that there are a lot of ill-defined concepts concerning dependencies, and so we rather not get entangled in a semantics debate. The library is modeled on storing all dependencies in a global, and in particular in a @TaskLocal to make it concurrency safe. If that makes it a "service locator" by ones definition, then so be it, but we prefer to compare approaches by the features and ergonomics they tangibly provide.

2. Everything always need default value which is not my cup of tea.

• I'm not sure what's the reason behind this idea. But could be better if we can interchangeable between creating new object & shared object.

Would you rather your app crash when asking for a dependency that has not been provided? There are two ends of the spectrum:

• You either pass all dependencies explicitly through initializers, which means if you have a series of features A -> B -> C -> D -> E, and E needs a UUID dependency, then A, B, C and D all must add the UUID dependency to their initializers just to pass it down to E. And that's true even if A, B, C, and D do not want to use this dependency.
• Or, you provide a global set of dependencies that features can freely grab from. But then this means all dependencies must be known the moment the app launches, which is often difficult if not impossible. Or you can not require all dependencies to be known at launch, and then you have to crash if you access a dependency not yet provided.

And so our library tries to strike a middle ground between these two approaches. We do store dependencies in a global (a @TaskLocal to be precise), but we require at the very least a testValue to be provided so that there is always something to access. However, if you access a dependency that pulls the testValue (meaning it does not have a liveValue or has not be overridden), then the library emits a purple runtime warning letting you know that something is not right. We find that this provides a nice balance of power and ergonomics, but we understand it may not be for everyone.

• This behavior feels like this lib is very opinionated to 1 approach & not flexible.

Do you know of other dependency libraries out there that are not opinionated?

5. My build is slower because we must implement testValue inside the DependencyKey or TestDependencyKey. ( I put the code below for example of what I did)

• The code also build the Mock classes. I'm aware it's lightweight, but if we have many mock classes in the entire project, the time adds up. It's better to not compile it at all.
• I think this is the limitation of the current protocol conformances. Can we think of another way to achieve this?
• I'm not sure if this is known issue/not. But IMO this is a big issue & deal breaker for me to adopt this lib further. Please let me know if we can have a workaround to solve this.

I personally find it hard to believe that your build is demonstrably slower. The testValue should be the absolutely bare minimum to implement the interface of your dependency. In fact, our documentation recommends implementing what we like to call an "unimplemented" conformance, which is one that simply reports an issue in each endpoint:

protocol UseCase {
  func method()
}
struct UnimplementedUserCase: UseCase {
  func method() {
    reportIssue("Unimplemented: \(Self.self).\(#function)")
  }
}

This is a great default implementation of the UseCase protocol because if it is every used in a test it will cause a test failure. This forces you to override the dependency if the code you are exercising uses this dependency. And further, it should compile instantaneously. You could have thousands of these implementations and there really shouldn't be any compilation cost, at least relative to the rest of the app.

And further, if you use the struct-style of dependencies, along with the @DependencyClient macro, this is all done for you:

@DependencyClient 
struct Client {
  var fetch: () async throws -> Int
}
extension Client: TestDependencyKey {
  static var testValue: Client { Client() }
}

The Client() value is provided by the macro and simply invokes reportIssue in each endpoint.

---

So, what you are seeing is indeed the intended behavior of the library and not likely to substantially change unless there is a way to still achieve all the things we are currently.