Dynamic dependencies

[stephencelis]

In announcement thread, @tylerjames asked a great question about using the new style with more "dynamic" dependencies.

I'm curious how you can use the @Dependency system for dependencies that are not static and that require some dependencies of their own in order to be constructed. For example a SmallFeatureClient that uses a much bigger HTTP client with endpoints used by the rest of the app.

I have started integrating TCA into some leaf nodes of my app and putting those features into modules. Consequently I have a huge "outside world" where my API clients and the rest of my app lives and my feature's initial State, Environment, and Store would be constructed by some non-TCA code. My SmallFeatureClient would get passed an API client in its initializer (or maybe something that access user prefences) and it would use these outside world dependencies to do work inside the closures required by the SmallFeatureClient.

I'm not sure how to build my SmallFeatureClient in the outside world and then pass it into my pristine TCA feature module.

Root-level configuration

Before introducing the reducer protocol, we typically described the "environment" of the reducer as a static set of dependencies for your application that is supplied at launch. This meant that dependencies that depended on one another needed to be assembled and pieced together carefully in order at the app's entry point.

You can still do this kind of work by assembling dependencies that need some dynamic configuration at launch, and then invoking ReducerProtocol.dependency(_:_:) on the reducer you pass to the store:

let apiClient = APIClient(configuration: ...)
let smallFeatureClient = SmallFeatureClient(apiClient: apiClient)

// ...

Store(
  initialState: AppReducer.State(),
  reducer: AppReducer()
    .dependency(\.apiClient, apiClient)
    .dependency(\.smallFeatureClient, smallFeatureClient)
)

Slicing large dependencies into smaller endpoints

The new style also makes it easier to explore alternatives, though!

For one, if SmallFeatureClient is just a slice of APIClient that forwards a few endpoints to the feature, you could consider giving the feature APIClient and expanding key paths to those specific endpoints directly in the reducer:

struct SmallFeature: ReducerProtocol {
  @Dependency(\.apiClient.fetchCurrentUser) var fetchCurrentUser
  @Dependency(\.apiClient.fetchTimeline) var fetchTimeline

  // ...
}

We can think of @Dependency use as mostly "static" still: you can access part of a static value that was supplied at the root of the application, but may have been transformed in some way by a parent via ReducerProtocol.dependency.

While you might worry about exposing the entire API client to this small feature, we think that clients should be super lightweight interfaces that compile almost immediately, and if the live dependency is heavyweight, it can be separated into its own module that the feature does not depend on.

Dynamic leaf configuration

There's also the idea of a "dynamic" dependency: a dependency that relies on some configuration that may differ depending on where the reducer is installed in the reducer tree, or some other dynamic value (in the environment or even state). For example, maybe you have a generic reducer that can render any kind of "timeline" data so long as it can fetch a timeline. Rather than use @Dependency, you would let the reducer be configurable with a local dependency that the parent can supply:

struct Timeline<Item: TimelineItem>: ReducerProtocol {
  let fetch: () async throws -> [Item]

  // ...

  func reduce(into: inout State, action: Action) -> Effect<Action, Never> {
    switch action {
    case .onAppear:
      return .task {
        // fire off request to fetch items
        await .response(TaskResult { try await self.fetch() })
      }

    case let .response(.success(items)):
      // do something with items

    // ...
    }
  }
}

Then a parent could configure this using a more static global:

struct Home: ReducerProtocol {
  @Dependency(\.apiClient) var apiClient

  // ...

  var body: some ReducerProtocol<State, Action> {
    Scope(state: \.chronologicalPosts, action: /Action.chronologicalPosts) {
      Timeline(fetch: self.apiClient.fetchChronologicalPosts)
    }

    Scope(state: \.recommendedPosts, action: /Action.recommendedPosts) {
      Timeline(fetch: self.apiClient.fetchRecommendedPosts)
    }

    // ...
  }
}

"Computed" dependency values

It's also possible to expose dependency values that are constructed out of other dependencies:

extension DependencyValues {
  var smallClient: SmallClient {
    get {
      // construct a small client from the current API client
      SmallClient(apiClient: self.apiClient, ...)
    }
    set {
      // intercept updates to `DependencyValues.smallClient`
      // and make appropriate changes to `self.apiClient`
      self.apiClient.(...) = newValue.(...)
    }
  }
}

Managing computed dependencies come with the same gotchas as computed state: you need to be careful about synchronization, and it can be verbose, but once everything is glued together it will let you avoid pushing this synchronization to the app entry point.

We haven't explored this too deeply, but wanted to share the idea.

---

These are just a few initial thoughts and ideas! Feel free to try them out or share your own 🤠

[oliverfoggin]

This is great and something I was going to ask too until I saw the topic already raised.

I'll definitely be exploring some of these ideas and report back.

Thanks 👍🏻

[tgrapperon]

The dynamic leaf approach looks like it can be "exploited" to make pieces of state travel through the environment in a standardized way. For example, with some parcel: Parcel piece of state, and a DependencyValue<Parcel> (modelized on EnvironmentObject) installed in \DepedencyValues.parcel, one can imagine:

// From a Root reducer
var body: some ReducerProtocol {
  Observe { state, _ in
    TruncReducer()
      .dependency(\.parcel, state.parcel) 
  }
}
// In a Branch reducer:
struct Branch: ReducerProtocol {
  @Dependency(\.parcel) var parcel
  var body: some ReducerProtocol {
    LeafReducer(parcel: parcel)
  }
}
// In Leaf reducer:
struct Leaf: ReducerProtocol {
  let parcel: Parcel
  func reduce(state: S, action: A) -> Effect<A, None> {
    switch action {
    case .onAppear:
      state.parcel = parcel
      return .none
    }
  }
}

Maybe this can be formalized into something more compact. For example, one can imagine the Store injecting the parcel into the state itself without involving the reducer's reduce/body. I think that the Store would need to hold onto the reducer's value for this to work (and this is problematic with the current toolchain). This is also a rough sketch, so one would need to explore invalidation, etc. But already without these hypothetical automatic amenities, it seems to provide a nice solution to the problem of making state data accessible at long distance. The dependency can be used in Leaf directly, without having it injected by Branch. This is a little different however, because the dependency value is only valid when the reducer is reducing, whereas its stored value is guaranteed to be something that's not the default, especially if force-unwrapped optionals are used like with EnvironmentObject.

[stephencelis]

Very interesting idea and use case of _Observe! (We underscored it to give ourselves more time to find use cases and potential other names.) Not sure all the pieces are together for it to work right now, but we should definitely explore this application.

[tgrapperon]

@oliverfoggin If the library provides:

struct DependencyValue<V>: DependencyKey {
  static var defaultValue: V! { fatalError(…) }
}

Then the user would only need to define

extension DependencyValues {
  var parcel: Parcel {
    get { self[DependencyValue<Parcel>.self] }
    set { self[DependencyValue<Parcel>.self] = newValue }
  }
}

In order to avoid this step, one can follow the path of @EnvironmentObject by making DependencyValue<V> a property wrapper:

@propertyWrapper
struct DependencyValue<V>: DependencyKey {
  static var defaultValue: V! { fatalError(…) }
  init() {}
  var wrappedValue: V {
    DependencyValues.current[Self]
  }
}

You would then simply use in Branch:

@DependencyValue var parcel: Parcel

It would need a custom writer.dependencyValue(_ value: V), similar to .environmentObject(object) in SwiftUI, to write into DependencyValues.current[DependencyValue<V>].
The main limitation is that it crashes by design at runtime if no value is set (a default value could probably be defined in the wrapper declaration if needed), and it only works for one value of a given type (but phantom types/wrappers could help discriminating).
In any case, it definitely looks like something interesting to explore.

[tgrapperon]

As I'm thinking about it, crashing by design makes sense when the value you expect is a reference type. For value types, we should be able to optionally provide a default value in the wrapper without consequences. Or we can use this to send a whole Store, and then it becomes a very different question!

[tgrapperon]

Here is a proof of concept of a simple @DependencyState property wrapper that works like @EnvironmentObject.

You inject the value as a function of State using .dependencyState(\.someInt) from a parent reducer.
You retrieve the value using @DependencyState var theInt: Int.
This one will crash with contextual information if you access it without having defined a .dependencyState() in a parent reducer upstream. Alternatively, you can provide a default value if you want to avoid crashing: @DependencyState(default: 100) var theInt: Int.

I've updated the case study, so the count you set from the counter in the Basic study is passed as initial count for the Shared study.

[tylerjames]

Okay great, this looks like it covers my use case.

I realize that gradually adding TCA into a legacy code base for which you might never make it to the point where you have a root reducer is not ideal but it's good to see that it's still supported. So far many of the dependencies my TCA feature clients might depend on are not themselves broken out into separate modules. I'm working at modularizing but the process can be a bit slow at times.

[Thomvis]

Looks like this can also replace something I've been doing with non-beta TCA. I have a withState reducer helper that allows me to define a reducer in terms of a piece of state. This works in tandem with a reusable reducer I've defined that can be used whenever a piece of state is loaded asynchronously. It's being used here.

[tylerjames]

Hey @stephencelis ,

I'm just trying to implement the Root-level configuration method you described above but I think I'm still missing something.

Referring to this code here:

let apiClient = APIClient(configuration: ...)
let smallFeatureClient = SmallFeatureClient(apiClient: apiClient)

Store(
  initialState: AppReducer.State(),
  reducer: AppReducer()
    .dependency(\.apiClient, apiClient)
    .dependency(\.smallFeatureClient, smallFeatureClient)
)

I can see how you create the dependencies and then assign them when initializing the Store but I'm not sure how you "register" the dependency keys used here .dependency(\.apiClient, apiClient). From the Speech Recognition sample code:

extension DependencyValues {
  var speechClient: SpeechClient {
    get { self[SpeechClientKey.self] }
    set { self[SpeechClientKey.self] = newValue }
  }
}

enum SpeechClientKey: LiveDependencyKey {
  static let previewValue = SpeechClient.lorem
  static let testValue = SpeechClient.unimplemented
}

Here it looks like the keys are statically assigned but how would that work with a dynamic dependency?

[tylerjames]

Okay I think I see how this accomplished.

In my DependencyValues extension I just provided .unimplemented versions of my client for each of the liveValue, testValue, and previewValue cases. Later when I launched the stored from my main app I injected a live version. Something like this:

extension DependencyValues {
  public var smallFeatureClient: SmallFeatureClient {
    get { self[ManageSiteClientKey.self] }
    set { self[ManageSiteClientKey.self] = newValue }
  }
  
  private enum SmallFeatureClientKey: DependencyKey {
    static var liveValue = SmallFeatureClient.unimplemented
    static let previewValue = SmallFeatureClient.unimplemented
    static let testValue = SmallFeatureClient.unimplemented
  }
}

And then later created the store like this:

let store = Store(initialState: initialState,
                  reducer: SmallFeature()
                    .dependency(\.smallFeatureClient,
                                 SmallFeatureClient(outsideClient: myOutsideClient)))

And that seems to be getting the job done

[stephencelis]

Glad you got it working!

[iwt-sebastian-boldt]

Wouldn't it also overwrite your preview and test values if you approach it like that?

[oliverfoggin]

@iwt-sebastian-boldt i don't think so as it's unlikely that this code will be run for previews or tests. This would only be run when the app runs and probably should exist somewhere like the AppDelegate or something.

[erudel]

Thank you @stephencelis for describing some of the alternative approaches for managing dependencies.


Just like we try to make invalid states impossible to represent for example with better use of sum types, I see a parallel in the definition of child environments where their construction at compile-time guarantees the availability of certain services in the reducer.

Leaning into the @Dependency system obviously has a lot of benefits that you showed in the protocol reducer announcement, in particular it avoids threading dependencies all the way down to the leaves. At the same time it also seems that some compile-time guarantees will be lost with this approach.

As an example, a network dependency of an authenticated user at the application’s entry point cannot have a meaningful default value and should only exist past the authentication flow. The “dynamic leaf configuration” approach seems an excellent way to avoid this problem, and I wonder if you have any thoughts on how this problem could be prevented using @Dependency?

Maybe the answer is simply that there are different approaches available and we should choose the right one for the job at hand, but I am nonetheless curious to hear your stance on this issue.

[stephencelis]

@jshier Just to revisit your original comment, are you still worried about losing anything from environment scoping? We think the scoping is still implicitly there via the reducer hierarchy, but if you feel like you've lost the ability to do anything in the migration we'd love to know about it.

[nikita-leonov]

@stephencelis Our conversation as expected starts to branch out into multiple different directions. I suggest focusing on the @Dependency pattern as a bigger change (at least for me) and discussing its challenges and as we agree on finalizing this branch try to return to other things as well.

The flaw of @Dependency as we see it in comparison with a singleton is the ability to initialize it with a different starting state. While in some cases default value can be considered a valid state I believe for many real-life scenarios initialization of dependencies requires other dependencies. This means it requires outside not-static initialization and not default value one. The incorrect state for such scenarios is a default value. For such cases, timing is important, if you tap into the property before it was initialized from outside with a properly initialize dependency you will get an incorrect state as a default. This is where the @Dependency looks awkward for dependency management purposes. Meanwhile, as you pointed out this is additive change, and injection of dependencies at the initialization stage is still an option, so there is always a way out. However, having multiple strategies for dependency management as well as a need to think if @Dependency use in some specific cases is ok or not looks like a consistency issue in comparison with an older approach. Not the end of the world, but definitely triggers the attention of some purists around.

[stephencelis]

@nikita-leonov I don't think that adding a new option is a bad thing here. I don't think it dilutes or muddies things in the general case. The older approach had some real usability and ergonomics issues. The vast majority of dependency passing is not the non-defaultable example that you give. We even think that having both options for managing dependencies is a good thing. For simple applications, @Dependency and its values will allow folks to get testable features written quickly and without fuss. And for advanced applications, we think teams will be able to describe to members when and where @Dependency is appropriate, or, if a team is worried and wants to prescribe a universal approach, they are free to lint all uses of @Dependency away. (We'll do our best to provide documentation to steer folks and teams in the right direction, but even in lieu of that we hope that this is generally an improvement to all.)

Just to reiterate, we believe that @Dependency is purely additive sugar that helps the general use case and is good for the library, and you and your team are free to ignore it or build style guides around it.

I'm more interested in specific examples of your requirement of "the ability to initialize it with a different starting state." What is a problem you've encountered that you haven't been able to solve (with @Dependency or without it)? And can you provide some sample code for us to help you solve the problem?

[nikita-leonov]

Thanks, @stephencelis. I definitely see how it makes it easier to deliver small features where environments are independent and can be initialized at any moment statically i.e. where the default value is always a correct one. As we indeed still have an injection into the initializer available and @Dependency is just an additive non-mandatory change we still can implement everything we need. To use or not to use the property wrapper for dependencies can be for sure a decision for each individual team. Knowing that Apple had its reasons to introduce Environment in SwiftUI it is probably correct to assume that the same reasoning may work for the majority of TCA consumers.

There are no use cases that are impossible to implement with new changes, however since we are on the topic of environments and dependencies, and since we already slightly touched it let’s review some use case that looks a little bit odd. Our app has app level environment and authenticated environment. Both environments have services to perform network calls, however, the authenticated environment has services pre-initialized with user information, auth tokens, etc to perform authenticated calls. This does look a little bit odd as environments are in some way becoming stateful, as every service definitely stateful with auth information cached. I think the best option would be that the user id, as well as auth tokens, etc would be stored in a state and networks call when performed are parameterized with this information on demand from the state. However, this makes it introduces some boilerplate in each of the reducers. I can imagine a scenario where the child reducer provides some part of the context for the network request and the parent reducer adds auth data and performs the network call, but this sounds like the whole network state needs to be engineered on top of TCA.

Let me know if more clarification is needed on the use case we have, as it seems like a lot of writing as a result even though problems sound simple and supposed to be common.

[stephencelis]

@nikita-leonov I think we'd definitely need a demo to work with to delve into any details for your use case, but to your points:

This does look a little bit odd as environments are in some way becoming stateful, as every service definitely stateful with auth information cached.

I'm not sure this should look odd! Let us know if we've ever given the impression that stateful environments are wrong and where, but we've been hiding away simple, mutable state in the environments of our public projects for a long time 😄

We think of the "environment" as being super stateful. It's the unknowable, untestable outside world that we need to control in order to get a handle on our domain's logic and behavior. Even though UUID() and Date() are simple static endpoints, the values they return are coming from super stateful places. And your domain-specific dependencies can be stateful as well. You can have an APIClient dependency that knows if it's logged-in or not without separating it into separate static environments. We're not even sure it makes sense for your app to separate "authenticated" vs. "non-authenticated" environments statically (though we're definitely interested in hearing about those reasons). Instead of static separation, you could have an APIClient in your environment that is either logged-in or logged-out and manages this mutable state internally, and you can manage loading logged-in state either inside your reducer (via applicationDidFinishLaunching or sceneDidChange), or outside your reducer (via an injected .dependency).

I think the best option would be that the user id, as well as auth tokens, etc would be stored in a state and networks call when performed are parameterized with this information on demand from the state.

If this state is internal to your dependency, we see no reason to manage it in app state. If anything, we think the dependency should manage it, and if a screen needs to render it in some way, the dependency should expose a way to fetch or subscribe to the latest value. In general, things in your app state should either render to the UI to be crucial to the decision as to whether it is rendered or how it is rendered.

Now it may seem wrong to push some stateful things into your application and some stateful things into your (live) dependencies, but we think there's a distinction:

1. Stateful things in your application are in testable reducers, and ideally there is complex business logic to contend with.
2. Stateful things in your dependencies should be for the most part logicless. You have a request that you send to a service and some expected responses that may get cached in dependency state in some way. That's not to say that your reducer's effects can't have logic (that's totally fine and is totally testable, since the reducer creates these effects), but you should minimize the surface area of what each dependency.endpoint can do.

At the end of the day there will be some nuance in deciding where to draw the line, just like there are decisions to be made when @Dependency vs. let-passing is appropriate. We'll do our best to lead by example, but we definitely don't want to require arbitrary barriers and boilerplate.

[DanKorkelia]

I'm having an interesting failure on Xcode Cloud. Everything builds/runs/tests locally but on Xcode Cloud CI.

Error from build logs. Not sure if it's Beta issues or not. Started happening after using DependencyValues.

1.	Apple Swift version 5.7 (swiftlang-5.7.0.123.8 clang-1400.0.29.50)
2.	Compiling with the current language version
3.	While evaluating request TypeCheckSourceFileRequest(source_file "/Volumes/workspace/repository/Modules/Sources/AppCore/Dependencies.swift")
4.	While evaluating request TypeCheckFunctionBodyRequest(AppCore.(file).DependencyValues extension._@/Volumes/workspace/repository/Modules/Sources/AppCore/Dependencies.swift:39:9)

[DanKorkelia]

Just coming back to report that yes it was #if DEBUG. That fixed the production/ci builds.

It does seem like a bug as there is no clear error why it's happening. Normally with if DEBUG there is a more meaningful error.

Thank you @tgrapperon and @stephencelis and Brandon for reporting the issue.

[tgrapperon]

Great!
I'm a little puzzled that Xcode Cloud manages to build using LiveDependencyKey. I was thinking it would refresh dependencies each time. If the package resolution is not committed in the repo, what will happen when the project will make the switch to DependencyKey? And if it is committed, where is it? I've just updated my main project's packages. A few have been bumped, but Git says there are no changes. Any idea?

[DanKorkelia]

I actually did update to DependencyKey.

Interestingly it seems to mean I now need to set live on reducer. Or am I missing something?

[tgrapperon]

As far as I know, if you were only using LiveDependencyKey and have renamed them DependencyKey, it should work without having to specify anything else. However, DependencyKey was also present in the previous commits (and is now renamed TestDependencyKey), so I'm wondering if it is not using a former version of protocol-beta. Do you have the issue locally, in Xcode Cloud or both?

[stephencelis]

@tgrapperon The issue is .unimplemented was unavailable in the release build Xcode cloud was kicking off, but it causes a compiler crash, not a build failure. Hopefully this diagnostic will improve in Xcode 14.1! We imagine many TCA users may encounter it 😬

[pteasima]

Great thread.

I have some past experience passing dependencies to other dependencies in SwiftUI.Environment and some thoughts how it might look in TCA. However, I have a problem with one of the premises of this discussion.

@stephencelis, in your original post, you explore ways to pass an APIClient to SmallFeatureClient. However, such a SmallFeatureClient isn't fully customizable. Its not necessarily enough to have access to APIClient. What if I want to overhaul the behavior of SmallFeatureClient significantly, e.g. I want to internally replace APIClient with FirebaseClient or TestDatabaseClient, possibly with much different api. The original definition of SmallFeatureClient can't possibly predict which other dependencies besides APIClient a future customized implementation might want to access. I would argue that as a service-layer object (i.e. "a thing that makes side-effects"), SmallFeatureClient should have access to all the rest of the service layer (i.e. all the other DependencyValues, i.e. all other ways to make side-effects). I've discussed this topic with a colleague in the past, and was told there's some prior art in redux, where middleware can access other middleware, but please take this with a grain of salt.

There are downsides to having this "full access":

• There are some risks with recursive access / infinite loops, but in practice I don't find these significant.
• I don't yet fully understand the semantics of @TaskLocal and other concurrency features, but I feel like there might be hidden trouble there.
• Giving everything access to everything possibly creates "too many" customization points. Without knowledge of the internals of the whole dependency graph (e.g. without knowing that SmallFeatureClient.live uses APIClient internally), you might run into surprises (e.g. you customize APIClient but don't expect SmallFeatureClient to be affected). However, I don't consider this too dangerous, given that it doesn't affect the live (non-customized) dependencies.

I wonder whether or not folks think it would be desirable to have full access to all DependencyValues in dependencies, regardless of how it would be achieved.

[katovBash]

It's a real good discussion, but I have some question what approach is better? :-)

Case 1:

• I have host module. That module contains sub modules that responsible for a single features.

• Also I have dependency, that I need to use only in this module.

Is it a good approach to use my dependency from @dependency?

I think in this way:
As I don't need this dependency from another modules, I can create it only in host reducer.
Also, if my children reducer need dependency from my host reducer, I will just specify the type of the desired object and initialise it already in the host.

Case 2:

• I have the same conditions.

• My child reducer can use dependency from @dependency each time, or I can just specify the type of it and lately use in hostReducer?

[pteasima]

@katovBash please consider posting a separate discussion, mark it as Question, include some code examples. Im not sure I fully understood the question, but one thing I wanna point out (that might be helpful), is that DependencyValues (just like SwiftUI.EnvironmentValues) are extensible via computed properties. So its ok for some modules to import and use (or define and use) a dependency that other modules might not even know about. In practice, the root of your app will likely have access to all dependencies, but afaik thats not a technical requirement.

[niorko]

With Swinject, we could define assemblies for different scopes, and then based on the context those assemblies could be applied.

Example:

We have an application that requires dependencies to be in these modes:

• real
• test / preview
• demo

Real mode and test / preview scopes are implemented, but to be able to run the app in the demo mode, it would require manually overriding every dependency.

This is an example of the entry point of the app that requires demo mode:

Is there any simple and convenient way to introduce demo mode or switch it during the runtime other than overriding every service manually? I can imagine forking the dependency library and introducing a demoValue to the protocol. But maybe there is a more elegant solution.

[tgrapperon]

It's only a matter of taste in this case. The onboarding reducer could have used .transformDependency as well:

.transformDependency(\.self) {
  $0.apiClient = .noop
  $0.audioPlayer = self.audioPlayer
  $0.database = .noop
  …
}

There is specific logic under the hood to make .dependency(…).dependency(…).dependency(…)… calls relatively performant. But otherwise, both approaches should produce the same results.

This bundled approach is also the one used in swift-dependencies that has just been extracted from TCA. The main difference is that TCA is able to maintain a parallel with SwiftUI's environment style, but it is likely that ReducerProtocol will expose a .withDependencies { … } method someday¹.

Footnotes

1. .dependency() and .transformDependency() would really make sense if we were observing the dependencies, but this is not currently the case. It could happen someday however, so that's why I'm not sure that deprecating them would be the right call. ↩

[mbrandonw]

It feels that this topic should be split out into its own discussion, and probably even in the new swift-dependencies repo. If you want to continue the discussion, would you mind doing that?

I can imagine forking the dependency library and introducing a demoValue to the protocol. But maybe there is a more elegant solution.

That may make sense for dependencies that you created, but what about if your feature uses dependencies from the library or dependencies that others have defined? Like, say your feature uses @Dependency(\.date) from our library and @Dependency(\.locationClient) from a 3rd party library you are using. Those dependencies have no sensible definition of demoValue, and so the library would have no choice but to resolve testValue, previewView or liveValue when using it.

In fact, the demoValue concept seems to only make sense at the app level and not at the library level.

As an alternative to demoValue, one interesting thing you can do is reset all of the dependencies of the feature to their testValues, and then override the dependencies your demo needs:

Feature()
  .transformDependencies {
    $0 = .test
    $0.apiClient = .demo
    $0.locationClient = .brooklyn
    $0.userDefaults = .inMemory
    // ...
  }

This will make it so that if you use a dependency in Feature() that was not overridden you get a loud, purple runtime warning in Xcode when running in the simulator, and you get a test failure when running tests.

I just pushed this to show how it could be used in the onboarding flow of isowords where we want to run the game in a very controlled execution environment (e.g. no database access, no file access, no Game Center access, etc.).

This of course is not as strong of a guarantee as having a static initializer of dependencies (which was the case in TCA pre-ReducerProtocol), but it will at least provide some safety.

[stephencelis]

Just as another note, you can define helpers directly on DependencyValues to "scope" things:

extension DependencyValues {
  static var demo: Self {
    var values = Self.test
    values.apiClient = .demo
    values.locationClient = .brooklyn
    values.userDefaults = .inMemory
    // ...
    return values
  }

  // or, if just layering on additional functionality:

  mutating func demo() {
    // ...
  }
}

Then, when you transform the dependencies in your feature or tests, it can become a bit more succinct:

Feature()
  .dependency(\.self, .demo)

  // or, with a mutating func:

  .transformDependencies(\.self) {
    $0.demo()
  }

[niorko]

Thank you all for the input.

We have a data-layer heavy application. There are even a hundred APIs that are combined in repositories. Then use-cases call these repositories. (APIs -> Repo with heavy logic and multiple methods -> UC with the single method). For every use-case, there is a demo implementation and mock implementation for tests. Every Presenter/ViewModel has let's say 5 UCs.

The reason why we make demo/mock UCs instead of just mocking the API layer is, that it's really hard to construct those API data - structures are huge and business logic around that is also complex. In UC, there is like one method to override/construct. So it is easier to test and construct a demo VM for the screen.

I like the idea of defining a direct helper on DependencyValues as @stephencelis showed, it could work, but I am feeling like it would be odd to override hundreds of dependencies in there. With Swinject I would make two assemblies - one for demo and one for live and if it is necessary, then one for test - for every feature module and then compose them together and apply them based on the situation.

I will have to rethink the whole dependencies situation. I would like to get rid of the Swinject because of many reasons - which one of is that it's not as safe as your solution, but it will require a lot of thinking.

[stephencelis]

@niorko Without seeing some example code it's really tough to see why using "two assemblies" in Swinject would be much different than creating a couple helpers on DependencyValues and calling them. If you'd like to share some code that distills how you do this kind of thing today we can try our best to translate it over.