How to make a dependency of a protocol

[kakhaberikiknadze]

I'm trying to add a dependency that would use a protocol as a type. However, I'm not able to use some keyword.

private enum StylerKey: DependencyKey {
    static let liveValue: some StylerProviding = StylerProvider()
}

extension DependencyValues {
    var stylerProvider: some StylerProviding {
        get { self[StylerKey.self] }
        set { self[StylerKey.self] = newValue }
    }
}

Error: Cannot assign value of type 'some StylerProviding' (type of 'DependencyValues.stylerProvider') to subscript of type 'some StylerProviding' (type of 'StylerKey.liveValue')

What's the best practise?

I could try with any but then I won't be able to inject it where it's added as a generic constraint. (For instance, when I want to inject it inside a different Module).
e.g.

private enum StylerKey: DependencyKey {
    static let liveValue: any StylerProviding = StylerProvider()
}

extension DependencyValues {
    var stylerProvider: any StylerProviding {
        get { self[StylerKey.self] }
        set { self[StylerKey.self] = newValue }
    }
}

struct MyStruct {
    @Dependency(\.stylerProvider) var styler
    
    func test() {
        MyGenericStruct(styler: styler) // This would of course complain that 'any StylerProviding' cannot conform to 'StylerProviding'
    }
}

struct MyGenericStruct<S: StylerProviding> {
    let styler: S
}

Or is it in fact discouraged to use protocols with some?

[tgrapperon]

Hey @kakhaberikiknadze! If you want to use protocols, you should probably use existentials (any) all the way. The performance impact is something that is often mentioned, but it may be very marginal in your situation (if not all).

Another solution would be to redesign your dependency to not use protocols. See for example this section of the documentation, which is functionally equivalent to erasing your protocol. You can totally imagine having a generic init to this struct, to easily wrap your existing StyleProviding types.

There are other solutions, but this is likely the road I would take. Can you tell us more about MyGenericStruct generic requirement? Does StylerProviding have an associatedtype?

I'd also recommend to watch this WWDC session about any and some to get a better idea of the differences between the twos if you haven't done it already.

[kakhaberikiknadze]

Thanks for the answer. Yeah, it has an associatedtype as well as the most of the protocols I use. I guess type erasure would be the choice indeed. And actually, yeah, it makes sense not being able to use an opaque one here as the type inside the dependency won't be guaranteed to be the same as the destination, will it?

BTW, I know that's a totally different topic and if prefered I could open a different thread but any suggestions of dependency, let's call it, registration for different modules?

For example:

• we've got Module A with dependencies and a Module B with its own ones.
• Module A depends on Module B
• Styler would be a good example, so let's say Module B has some kind of scene factory createing views and needs stylers to do so. It doesn't have its own styler implementations. It just exposes protocols.
  • Factory returns either type erased or opaque views. The func would look like func getSceneA(_ styler: any SceneAStyling) -> some View (for this purpose let's just stick with an existential option).
• Module A has styler implementations that conform to those protocols.
• In a usual way you'd just pass around the injection as above and you'll need to explicitly add that styler in view's init as well.

Would it be somehow possible to make it this way:

• Module B register its own default styler implementations as dependencies.
• Module A override those dependencies so that every object in module B uses overridden ones?

[tgrapperon]

It may be hard to give general advises without seeing explicit code, but my gut feeling is that you're trying to build something in B like:

struct DependencyKeyB: DependencyKey {
  var doSomething: () -> X = {
 	@Dependency(\.dependencyA) var dependencyA;
    // Do something in B that depends on A 
    …
  }
}

So by default, B will use A defaults, but you can configure B using either B directly, or by modifying A onto B depends itself. Maybe I'm not seeing exactly what you're looking for as protocols are involved, so feel free to open a dedicated discussion with an explicit example if I'm not helping here.

[kakhaberikiknadze]

I've noticed I was using an old version of TCA where Dependencies library was included in the same package and noticed there was a new version where Dependencies is a separate repo and some override features are added that might be helpful. Hence, I'm looking through it 🙌🏻