Exploring Protocol Dependencies (in conjunction with @Dependency)

[JacksonUtsch]

In creating a dependency with a generic result type I've had to opt for using a protocol to declare its interface.

public protocol JwtClient {
  func decode<T: Codable>(_ token: String) async throws -> Result<T, Error>
}

Test and Noop implementations can follow as such

public struct JwtClientTest: JwtClient {
  public init() {}

  public func decode<T>(_ token: String) async throws -> Result<T, Error> where T : Decodable, T : Encodable {
    XCTFail("\(Self.self).decode is unimplemented")
    return try await Task.never()
  }
}

public struct JwtClientNoop: JwtClient {
  public init() {}

  public func decode<T>(_ token: String) async throws -> Result<T, Error> where T : Decodable, T : Encodable {
    return try await Task.never()
  }
}

extension Task where Failure == Never {
  /// An async function that never returns.
  static func never() async throws -> Success {
    for await element in AsyncStream<Success>.never {
      return element
    }
    throw _Concurrency.CancellationError()
  }
}

extension AsyncStream {
  static var never: Self {
    Self { _ in }
  }
}

You can then even extend the protocol to include a typealias for these.

extension JwtClient {
  public typealias Test = JwtClientTest
  public typealias Noop = JwtClientNoop
}

Such that when you must provide a concrete type you can use .Noop() or .Test()

I've found dependency injection via the feature works fine but does add an extra explicit requirement.

struct MyFeature: ReducerProtocol {
  let jwtClient: JwtClient

  init(jwtClient: JwtClient) {
    self.jwtClient = jwtClient
  }
}

I thought I would share this methodology on the forums if anyone needs the example.

---

This alternative route is needed because you cannot have generic properties on structs. Does anyone know a language that allows this? Wondering if there is a technical reason for such. It would seem to be logical for a definition to exist that looks like:

struct JwtClient {
  var decode<T: Decodable>: (Data) -> Result<T, Error>

  init<T: Decodable>(
    decode: @escaping (Data) -> Result<T, Error>
  ) {
    self.decode = decode
  }
}

Note, this would not require a generic in the type definition of JwtClient.

[mbrandonw]

While this seems to work at first blush, we have found it to be unwieldy in practice, and is one of the reasons we recommend the structified approach to dependencies.

The problem comes up when you try to provide an implementation of JwtClient that actually returns some data:

public struct JwtMock: JwtClient {
  public init() {}

  public func decode<T>(_ token: String) async throws -> Result<T, ApiClient.Failure> where T : Decodable, T : Encodable {
    ???
  }
} 

How are you supposed to return something from this when you know nothing about T? I suppose you check the type and do some force casting:

public func decode<T>(_ token: String) async throws -> Result<T, ApiClient.Failure> where T : Decodable, T : Encodable {
  if T.self == Int.self {
    return 42 as! T
  } else {
    return try await Task.never()
  }
}

But that seems really strange.

You can still model this dependency as a struct even if you can't use a generic in a property. You start with a field for the _decode endpoint that deals with plain, unstructured Data, and then you add a method decode that introduces a generic and performs the JSON encoding on the inside:

struct JwtClient {
  let _decode: (_ token: String) async throws -> Result<Data, Error>

  func decode<T: Encodable>(token: String) -> Result<T, Error> {
    // ...
  }
}

Then it is easy to cook up mock clients, and it comes with a bunch more benefits since it's a struct.

We discussed this at length in our "API clients for free" episode, and this is the style we use for the URL routing library we open sourced, which is used by isowords.

Now, you more than free to pursue the protocol style of this dependency if you prefer it. We understand struct dependencies aren't for everyone. But, even if you do use a protocol, you can still use it with the @Dependency style of dependency management. No need to pass it around explicitly.

[JacksonUtsch]

This is a great point. There would be difficulties with a mock implementation. In fact the best mock implementation might be the live implementation. Although, this could potentially cause SwiftUI previews to break and partially defeat the purpose of injection.

The strange solution you gave might be the way to go as it is only for mock implementations, you could prove improper usage with a fatal error if a type cast is not met. Agreed, it is not ideal.

..

My counterargument would be that the JwtClient you defined is not the same as the former. It does not abstract away the same code. Essentially the live implementation would have to exist inside the function for this to operate. My main purpose of this injectable interface was to remove a 3rd party dependency for non-live executables (tests/previews). So I do not see a way of the struct interface solving this.

[mbrandonw]

My counterargument would be that the JwtClient you defined is not the same as the former. It does not abstract away the same code. Essentially the live implementation would have to exist inside the function for this to operate. My main purpose of this injectable interface was to remove a 3rd party dependency for non-live executables (tests/previews). So I do not see a way of the struct interface solving this.

This isn't true. I omitted the implementation of decode for brevity, but this is what it would really look like:

struct JwtClient {
  let _decode: (_ token: String) async throws -> Result<Data, Error>

  func decode<T: Encodable>(token: String) -> Result<T, Error> {
    switch self._decode(token) {
    case let .success(data):
      return Result { try JSONDecoder().decode(T.self, from: data) }
    case let .failure(error):
      return .failure(error)
    }
  }
}

There is no mention of live JWT code in the interface. Only the actual live implementation (e.g. JwtClient.liveValue) would need to call out to 3rd party JWT code.

[JacksonUtsch]

I see, Data is being used here as an arbitrary result. The 3rd party package I'm using essentially exposes (String) -> Result<T, Error>

So what you are saying, could be achieved with the Codable assumption. That is very cheeky.

The implementation would encode the result rather than outputting the generic. And you would use JSONDecoder in the function which could be considered a dependency as well. 🤷‍♂️

I'd still think the JwtClient definitions are different as this is only possible with the Data type and the requirements of Encodable & Decodable

With different protocol requirements I do not think this could work. Correct?

[mbrandonw]

With different protocol requirements I do not think this could work. Correct?

I think this style can essentially always work, but the client may become more complicated as you use more complex generics features.

However, on the flip side, the more complex generics features you use in the protocol client, the more difficult it will be to write sensible mocks.

The two styles have their tradeoffs, but overall we have found the struct style to be slightly more flexible.