Additions suggestion/request

[wltrup]

Hi Thomas,

I'd like to suggest two additions to your dependencies library:

• a way to set the user interface style (ie, dark or light mode)
• a way to directly get and set dates in UserDefaults

Thanks!

[tgrapperon]

Hey @wltrup! Thanks for the suggestions!

I'll see if I can make the Dependency.Environment from _SwiftUIDependency property wrapper writable, so it injects the environment value at the same point it reads it.

About UserDefaults, I initially exposed what SwiftUI exposes through the AppStorage property wrapper, and UserDefaults through typed accessors, but you're right that UserDefaults also support writing Date directly, so I'll check if I can make it work nicely. It also should support arrays and dictionaries, so I'll check how far I can push the similarity of the API. I'll also try to guess why SwiftUI doesn't expose a Date specialization!

I'm also going to convert this issue into a discussion if you wouldn't mind, as this is not a direct problem with the library.

[tgrapperon]

I've already implemented Date support in UserDefaults. I'll cut a release in a few days.

[wltrup]

Wow, that was quick! Many thanks!!

[acosmicflamingo]

I suppose the question is to what extent these DependenciesAdditions modules should behave purely as abstractions of Apple frameworks as opposed to being a 3rd party dependency that happens to provide additional Apple framework behavior with mirrored API.

In the userInterfaceStyle example, there is no simple function from an Apple framework that allows you to override an app's userInterfaceStyle but it's certainly possible of course (which is what I do in a lightweight UIApplicationClient dependency):

public struct UIApplicationClient {
  public var setUserInterfaceStyle: @Sendable (UIUserInterfaceStyle) async -> Void
}

extension UIApplicationClient: DependencyKey {
  public static var liveValue: UIApplicationClient {
    return Self(
      setUserInterfaceStyle: { userInterfaceStyle in
        await MainActor.run {
          guard
            let scene = UIApplication.shared.connectedScenes.first(
              where: { $0 is UIWindowScene }
            ) as? UIWindowScene
          else {
            return
          }
          scene.keyWindow?.overrideUserInterfaceStyle = userInterfaceStyle
        }
      }
    )
  }
}

So should we expect Dependency.Application to have a setUserInterfaceStyle function even though UIApplication.shared does not have this behavior?

This question is also important because off the top of my head, there's tons of functionality I'd love to see in a hypothetical dependency like AccessibilityDependency. For example, UIAccessibility doesn't have a way of getting app's contentSizeCategory, but it'd be nice for @Dependency(\.accessiblity.contentSizeCategory) var contentSizeCategory to be possible. It would also mean I don't have to create my own A11yClient dependency since I could just use whatever would be in the DependenciesAdditions library.

[acosmicflamingo]

I should have read through all the discussions first before writing this since I think this exact topic is reflected in here: #9

[tgrapperon]

Hey @acosmicflamingo! I think that in a first time, we should mirror Apple's APIs in order to:

• Allow folks to transition their existing codebase "seamlessly" to controllable dependencies;
• Allow folks to define their own abstraction on top of these basic (but controllable) dependencies.

The second approach is what is explored with the underscored dependencies. It is very likely that they will be extracted from this library once they mature enough. I feel that having a unique repository with many opinionated dependencies would be very hard to maintain, and that will also go well beyond the intended scope of this library.

So I guess that, for now, the idea is to not add additional features to existing API's. One notable exception would be to convert to Swift concurrency the very few APIs with completion blocks that weren't automatically translated.

But you're free to build your own abstractions with more features on top of swift-dependencies and swift-dependencies-additions, and I'll happily link them in the README!