@DependencyClient macro

[stephencelis]

This PR adds a new DependenciesMacros¹ target to the library, which houses a couple macros that aid in designing dependencies for your application and for use with this library.

The main macro is @DependencyClient, which can be applied to the "struct of closures" style of dependency clients:

@DependencyClient
struct AudioPlayerClient {
  var loop: (_ url: URL) async throws -> Void
  var play: (_ url: URL) async throws -> Void
  var setVolume: (_ volume: Float) async -> Void
  var stop: () async -> Void
}

This does a few things for you. First, it automatically provides a default for each endpoint that simply throws an error and triggers an XCTest failure. This means you get an "unimplemented" client for free with no additional work. This allows you to simplify the testValue of your TestDependencyKey conformance like so:

 extension AudioPlayerClient: TestDependencyKey {
-  static let testValue = Self(
-    loop: unimplemented("AudioPlayerClient.loop"),
-    play: unimplemented("AudioPlayerClient.play"),
-    setVolume: unimplemented("AudioPlayerClient.setVolume"),
-    stop: unimplemented("AudioPlayerClient.stop")
-  )
+  static let testValue = Self()
 }

This behaves the exact same as before, but now all of the code is generated for you.

Further, when you provide argument labels the client's closure endpoints, the macro turns that information into methods with argument labels. This means you can invoke the play endpoint like so:

try await player.play(url: URL(filePath: "..."))

And finally, the macro also generates a public initializer for you with all of the client's endpoints. One typically needs to maintain this initializer when separate the interface of the dependency from the implementation (see
Separating interface and implementation for more information). But now there is no need to maintain that code as it is automatically provided for you by the macro.

Footnotes

1. DependenciesMacros is defined as a new module so folks do not automatically incur the cost of building SwiftSyntax, which macros depend on and is quite heavyweight. ↩

[mbrandonw]

Hey @brianmichel, we've been experiencing flakiness with windows CI and so have been slowly disabling them. Not sure if this is something you want to look into eventually.

[brianmichel]

Hey @mbrandonw sorry for the delay, we're in burn down mode for getting the first version of the Windows app out to a few folks, I'm not exactly sure what's going on here, but have a personal todo to take a peek once I have more free time.

[mbrandonw]

Hey @brianmichel, no problem at all! We're happy to turn it back on when possible, but definitely not urgent. Thanks for responding!

[hadiidbouk]

@mbrandonw @stephencelis Generating this part isn't included in the macro?

extension DependencyValues {
	public var myService: MyService {
		get { self[myService.self] }
		set { self[myService.self] = newValue }
	}
}

[mbrandonw]

@hadiidbouk that part cannot be generated by the macro. Macros are not capable of extending types other than the one it is attached to.

[hadiidbouk]

@mbrandonw Ohh I was hoping to avoid adding this boilerplate code, it's almost the same for all our dependencies.
Do you think something like #DependencyValues(myService.self) is doable?

[Sajjon]

Oh I've missed this, this is great!