Dependency Entry macro to mimic Environment Entry

[DominikGrodl]

A recent message on PointFree Slack made me think whether we could utilize a macro similar to the newly added Entry macro for registering Environment values in SwiftUI. I tried to sketch what that could look like here. Please keep in mind this is a piece of code for a quick demonstration purpose. I would love to make it more stable and polished (such as add tests) if we decide to go forward with this proposal.

This macro does not eliminate a lot of boilerplate, actually almost none, when looked at from the perspective of one dependency, but does help when emitting a large number of dependencies.

[mbrandonw]

Hi @DominikGrodl, thanks for taking the time to explore this!

The @Entry macro in SwiftUI does more than just add the computed property to EnvironmentValues. It also constructs a type that conforms to the EnvironmentKey protocol and provides the defaultValue requirement:

I think in order for a @DependencyEntry macro to carry its weight it would need to do something similar. But then things get complicated because our library has two important protocols: TestDependencyKey and DependencyKey. We're not sure what that would look like.

If you want to explore that then we'd be interested to see what you find.

[DominikGrodl]

Hi @mbrandonwc, thanks for the reply.

Yeah, I initially started with the goal of covering the whole functionality, but quickly realized that's a much bigger task. I'll try to keep working on it and see what I can come up with.

[BrentMifsud]

I'm not too familiar with writing macros.

Is it possible add optional parameters to them?

Something like:

@Entry(testValue: T?, previewValue: T?) var myDep: T

And if those values are omitted, it would behave as if you did not include a test or preview value.

[mbrandonw]

Hi @BrentMifsud, sorry didn't see this from a few months ago.

There are a few reasons this wouldn't work. First of all, there would be no way to statically tie the types of those arguments and the myDep, and so you would probably just get cryptic error messages if there is a mismatch, and you might even be forced to provide explicit type annotations to appease the compiler.

Second, a common pattern in the dependencies library (probably the most common) is to separate the interface from implementation in two separate modules. The style you have outlined would only be useful for people defining test/preview/live implementations in the same module, and so would probably not be useful to the vast majority of use cases.

And finally, even if the test/preview/live values of your dependency are really meant to be defined in the same module, at the call site this macro would be invoked like this:

extension DependencyValues {
  @DependencyEntry(testValue: APIClient.mock, previewValue: APIClient.mock) var apiClient = APIClient.live
}

struct APIClient {
  static let mock = APIClient(…)
  static let live = APIClient(…)
}

Is that substantially better than this:

extension DependencyValues {
  var apiClient: APIClient {
    get { self[APIClient.self] }
    set { self[APIClient.self] = newValue }
  }
}

struct APIClient: DependencyKey {
  static let testValue = APIClient(…)
  static let liveValue = APIClient(…)
}

?

Further, if you are using the struct style of dependencies, and if you are only registering a single version of the dependency, you can forgo the computed property on DependencyValues entirely:

struct APIClient: DependencyKey {
  static let testValue = APIClient(…)
  static let liveValue = APIClient(…)
}

@Dependency(APIClient.self) var apiClient

That is shorter than all the other versions, and is still flexible enough to handle all the different use cases of the dependencies library.