Custom dependencies contexts

[dankinsoid]

It would be nice to add the possibility to define custom dependency contexts or customize the current context detection.

I have two ideas:

1. Context as an associated type in the DependencyKey protocol:

public protocol DependencyContextType {
   static func detect() -> Self
}

public protocol AnyDependencyKey<Value> {

    associatedtype Value: Sendable = Self
    associatedtype Context: DependencyContextType = DependencyContext
    static func value(for context: Context) -> Value
}

public protocol TestDependencyKey<Value>: AnyDependencyKey where Context: TestDependencyContext {

    static var previewValue: Value { get }
    static var testValue: Value { get }
}

extension AnyDependencyKey where Self: TestDependencyKey {

  public static func value(for context: TestDependencyContext) -> Value { ... }
}

public protocol DependencyKey<Value>: TestDependencyKey where Context == DependencyContext {

    static var liveValue: Value { get }
}

extension AnyDependencyKey where Self: DependencyKey {

  public static func value(for context: DependencyContext) -> Value { ... }
}

// Override default context:
func customize() {
    withDependencies {
        $0.setContext(
            for:  CustomContext.self, 
            Environment.isMock ? .mock : Environment.isProd ? .prod : .dev
         )
    } operation: {
        ...
    }
}

2. Optional method in the DependencyKey protocol:

enum MockContext: CustomDependencyContext {
}

enum SomeDependencyKey: DependencyKey {

   static let liveValue = "Live"
   
   static func value<C: DependencyContextKey>(for context: C.Type) -> String? {
      if context is MockContext.Type {
         return "Mock"
      }
   }
}

[dankinsoid]

Live/test/preview combinations are suitable for UI app development, but for backend development, I would like the possibility to define custom environments like dev/prod/mock/stage, etc.

[mbrandonw]

We think that liveValue/testValue certainly makes sense for backend development too, after all we do use swift-dependencies in the Point-Free codebase. The previewValue definitely doesn't make as much sense, and in fact I could even see us guarding that in a #if canImport(SwiftUI) to make it clear it's only for SwiftUI apps.

An extensible and customizable "context" system is interesting, but I'm not sure I understand the changes you are proposing. Could you flesh out a more complete, compiling example?

Also I think the use cases would need to be justified a bit more. For backend apps we've actually had no problem whatsoever with using swift-dependencies. In our view, running an app locally, or on a staging server, or on a production server are all "live" environments. We don't think dependencies should be customized based off of those environments.

Instead, dependencies should take their configuration from environment variables set on the machine, such as POSTGRES connection details, private API keys, app secrets, and more. That lets the dev/staging/prod machines decide what databases and services are being connected to.

[dankinsoid]

@mbrandonw Hi, here is a compiling example:
CustomContexts.playground.zip

I thought about custom contexts while working on one of my backends. I have three environments: production, development, and mock. While production and development are configured through environment values, mock is much different. My backend works with many external services that require user authentication and don't have test APIs, so it's convenient for development purposes to replace them with mocks while keeping other functionality. Now I configure all these dependencies at the server start, but it would be more appropriate to define them with dependency keys. I don't know, maybe my case is very specific, and there is no need to support such cases in the core library.