Shared dependencies across multiple features

[fbp93]

I have a question regarding a limitation of shared dependencies.
Usually, if you have a dependency that is used by multiple features, you can move it to a proper module so that each feature just need to import that module and you can pretty easily add the dependency because you know they key.
For example the apiClient you defined in isowords it's a separate module and each feature can use it.
There may be two cases where I don't wanna move this dependency in a shared module but still I would like to reuse it in multiple features:

1. The dependency is pretty simple (e.g. a closure () -> Bool)
2. The dependency is scoped from another one
   I m gonna focus in the point 2 because is the complex one and most interesting.
   I have library that define a Tracker:

public struct Tracker<Event> {
  var track: (Event) -> Void

  public init(track: @escaping (Event) -> Void) {
    self.track = track
  }

this is basically a witness to be able to track metrics or logs and the live implementation can be a network call that is sending data to your backend or just a print on the console.
This model is generic over the Event, so that I can reuse it across different apps.
The main event is defined in the main target as:

enum AppEvent {
  case featureA(FeatureAEvent)
  case featureB(FeatureBEvent)
  ...
}

Ideally I would like that my main target is working with a dependency of Tracker<AppEvent> and scope this dependency in each single feature, for example FeatureA will has Tracker<FeatureAEvent>, FeatureB will has Tracker<FeatureBEvent> etc.
This is something I was already doing before the new dependency management system.
The huge problem is that my feature doesn't know anything about the AppEvent and I don't want that it knows it.
So I was forced to define a new dependency key in my FeatureA to make it compile:

@Dependency(\.featureATracker) var tracker

....

public struct FeatureATrackerKey: TestDependencyKey {
    public static let testValue: Tracker< FeatureAEvent > = .init(track: { _ in  })
}

extension DependencyValues {
    public var featureATracker: Tracker< FeatureAEvent > {
      get { self[FeatureATrackerKey] }
      set { self[FeatureATrackerKey] = newValue }
    }
}

(notice that live implementation is not handled because it will be provided by the main target).

Then in the main target I define the main Tracker dependency

@Dependency(\.mainTracker) var tracker
....
struct MainTrackerKey: DependencyKey {}

extension DependencyValues {
    var mainTracker: Tracker<AppEvent> {
        get { self[MainTrackerKey.self] }
        set { self[MainTrackerKey.self] = newValue }
    }
}

and I made the feature A tracker depending on the main one only at a live implementation level

extension FeatureATrackerKey: DependencyKey {
    public static let liveValue: Tracker<FeatureAEvent> = {
        return MainTrackerKey
            .liveValue
            .scope(AppEvent.featureA)
    }()
}

This approach works but it has 2 issues:

• Adding a new dependency to the feature is no more a single line change, every time I had to use a new key because it's not aware of key of the main tracker
• Both trackers depends only at a live implementation level, but they are actually two different dependencies. In fact, in integration tests I have to override the right dependency otherwise it doesn't work. Possibly if I have a test that use the trackers in N features, I cannot override only the main tracker implementation, I have to override all the N implementations, one for each key.

Do you have any suggestion on how to solve this? I think it's a big limitation compared to the previous state of the library, because it's forcing me to move things in separate module when I don't want to or I may not be able to do (e.g. the generic Event may contain a lots of models, due to legacy reasons that I would like to avoid to expose to all feature that use the dependency).
Thanks!

[Malauch]

Do you have any suggestion on how to solve this? I think it's a big limitation compared to the previous state of the library, because it's forcing me to move things in separate module when I don't want to or I may not be able to do (e.g. the generic Event may contain a lots of models, due to legacy reasons that I would like to avoid to expose to all feature that use the dependency).

Because you mention "previous state of the library", I assume that you are talking about using Dependencies in TCA. I tried to experiment with similar situation and could not find any solution which is not clunky. Therefore my conclusion was that @Dependency is for dependencies which don't have to be composed across features. If you need this kind of client composition then you can still use old style of passing client from Reducer to Reducer within init.
However my solution was to make client more barebones and using just raw types like String, Data etc. and just remove generic from Client. Then do that translation from specific type like Event to these raw types in reducer, which can be stand alone reducer composed with feature or higher order reducer. In short all composition part moved to reducer composition and client interface refactored to be minimalistic and universal.

[mbrandonw]

Just to reiterate @Malauch's point: if you were using dependencies in TCA in a particular before the new @Dependency style, then you should be able to continue doing that.

In particular, suppose you had a feature that wanted to track an analytics event, but didn't want to have to depend on the full AnalyticsClient dependency. Then it can just hold onto a void-to-void closure:

struct ChildFeature: ReducerProtocol {
  struct State { … }
  enum Action { … }

  let trackChildEvent: () async -> Void

  …
}

And the parent, who does have access to the AnalyticsClient dependency, can derive that void-to-void closure and pass it down:

struct ParentFeature: ReducerProtocol {
  struct State { … }
  enum Action { … }

  @Dependency(\.analyticsClient) var analyticsClient

  var body: some ReducerProtocolOf<Self> {
    ChildFeature(
      trackChildEvent: { self.analyticsClient.track(.childEvent) }
    )
  }
}

It is completely fine for a feature to hold onto dependencies without using @Dependency where it makes sense. In fact, we have an example of this in the "reusable favoriting component" case study, where the component does not use @Dependency because it should be passed in explicitly from the parent.

[fbp93]

Thanks @mbrandonw !
I still have one doubt. Even if your approach is totally feasible and it works, I still have the feeling that is due to some sort of limitation of the library. Ideally I would like to being able to always define dependencies in the same way (e.g. with the property wrapper @Dependency) and not being forced by a library to change a signature or how the dependency is passed to make it work in this way. When I write a new feature I would like to think about it in an isolated way without caring about where the dependency is actually defined (e.g. main target, shared module etc) in order to use the best approach (@Dependency vs property). Isn't it?

[mbrandonw]

It's hard to say whether this is a library deficiency for your particular situation because I'm not sure I 100% understand it, but I can say for sure that it is not a deficiency for the use case I outlined above with the reusable favoriting component.

The purpose of that component is to be generic, and it's not possible to put a "generic" dependency into DependencyValues. At least not in a type safe way. You could maybe stick in a Client<Any> and come up with ways to transform it into more specific Client<A>'s, but that would have to deal with the potential to fail.

So, in our opinion, it is completely fine for that highly generic, reusable component to statically describe it's dependencies as lets, and then the parent domains can leverage @Dependency in order to grab a dependency and transform it into something the component can use.

It may be helpful if you can cook up a sample project that is in compiling order and shows how you wish you could model your dependencies vs how the library currently makes you model the dependencies. That would make it more concrete for us to understand what it is you are trying to do.

[fbp93]

Thank you @mbrandonw I ll try this approach for now and in case of doubts I'll get back to you!

[ldstreet]

I approached this by keeping my shared tracker using freeform data:

struct Tracker {
    var track: (String, [String: String]) -> Void
}

I can then implement this client using my analytics engine of choice in a separate impl module.

Then, to get type safety I create a protocol to structure the data:

protocol Event {
    var title: String { get }
    var properties: [String: String { get }
}

and an extension on Tracker to accept types conforming to Event.

extension Tracker {
    func track(_ event: Event) {
        track(event.name, event.properties)
    }
}

enum FeatureAEvent: Event {
     case tappedContinue

     var name: String {
         switch self {
         ...
         }
     }

    var properties: [String: String] {
         switch self {
         ...
         }
     }
}

Now I can define my events local to each module without any need to override the environment.