Best Practices for nested function calls in dependencies

[alinless]

I would like to make a nested function call within a client. For instance, I need to invoke the second function call inside the first function call. While we can certainly use a third function to handle the request, are there any other alternatives available?

public struct ApiClient: Sendable {
   public var firstRequest: @Sendable () async throws -> String
   public var secondRequest: @Sendable () async throws -> String
}

extension ApiClient: DependencyKey {

   public static let liveValue = Self(

      firstRequest: {
         return try await secondRequest // ??
      },
      
      secondRequest: {
         return try await thirdRequest()
      }

   )
   
   static func thirdRequest() async throws -> String {
      return ""
   }
   
}

[mbrandonw]

If you want to use the struct-style of dependency then what you have sketched out is probably the best way to handle it. If that style is too onerous then you could try going back to the protocol style.

Also, is there a chance that secondRequest shouldn't be apart of the implementable API of the client, but instead should just be a simple func?

Like this:

public struct ApiClient: Sendable {
  public var firstRequest: @Sendable () async throws -> String

  public func secondRequest() async throws -> String {
    // Do stuff
    return try await self.firstRequest()
  }
}

Should people be allowed to override secondRequest independently of firstRequest? Or does secondRequest always perform the same logic and just call firstRequest under the hood?

[alinless]

Yes, it is better to incorporate it as part of an implementable API.
The idea is to utilize the same async logic and keep it within the same API client. For instance, provide each request with the ability to use an inner second async request in order to avoid code duplication. The func was just a bad example. Is there a better way to handle it?
For example, is it safe to use a dependency in this way?

firstRequest: {
 @Dependency(\.apiClient) var apiClient
 return try await apiClient.secondRequest()
},

[mbrandonw]

Yes, you can do that, but you have to be aware of all the caveats of using @Dependency in an escaping closure like that, unless you are using a single-entry point system such as the Composable Architecture.

Here are some articles from the docs for you to learn about these subtleties:

• https://pointfreeco.github.io/swift-dependencies/main/documentation/dependencies/lifetimes
• https://pointfreeco.github.io/swift-dependencies/main/documentation/dependencies/singleentrypointsystems

I personally think using a helper function to share the logic is better, and avoids the caveats detailed in the above articles.

There's also a chance that a protocol version of this dependency is a better fit since there is a dependence between endpoints. It seems dangerous to me to have a live client where secondRequest calls firstRequest under the hood, but then in tests you an override those endpoints to do completely different things.

[alinless]

Sure, thank you so much! Your help is greatly appreciated