Beginner question: why would I use this vs passing dependencies in initializers?

[Pikuseru]

Hello there, this is a question from a beginner, but I'm not sure why I would want to use this - and have my code needing to use a library, am I tying myself into the use of the library to structure my code?

I don't quite understand what benefits this is giving me over passing dependencies in initialisers, and then I can see what the code depends on by it needing it to initialise itself?

And if there's something, A that depends on B, should there not be something else that gives A the B it needs to work, without A knowing how it gets given it?

Apologies if this question is a bit dumb or silly.

[mbrandonw]

Hi @Pikuseru, this isn't a silly question, and probably something we could cover better in the docs somewhere. Though hard to know if people would read it!

Your question really goes to the root of why one would use a dependency management library, period. Not just this one, but any library.

The benefits don't really show themselves when considering a feature A that creates a feature B. In such a situation passing dependencies explicitly isn't really that big of a deal. The real benefit comes when having dozens or even hundreds of features.

Suppose you have feature 1 through 4, where feature 1 can navigate to 2, 2 can navigate to 3, and 3 can navigate to 4. And further suppose that feature 4 really needs a date generator dependency so that it can keep its logic testable. Then feature 1-4 all need the date generator, even though only feature 4 needs the dependency:

struct Feature1 {
  let date: () -> Date
  init(@escaping date: () -> Date) {
    self.date = date
  }
  func goToFeature2() {
    … = Feature2(date: date)
  }
}
struct Feature2 {
  let date: () -> Date
  init(@escaping date: () -> Date) {
    self.date = date
  }
  func goToFeature3() {
    … = Feature3(date: date)
  }
}
struct Feature3 {
  let date: () -> Date
  init(@escaping date: () -> Date) {
    self.date = date
  }
  func goToFeature4() {
    … = Feature4(date: date)
  }
}
struct Feature4 {
  let date: () -> Date
  init(@escaping date: () -> Date) {
    self.date = date
  }
}

And one could argue that it's good that feature 1-3 are forced to have a date dependency since they all depend on feature 4, and feature 4 needs it. But I'm not sure that is really all that valuable compared to all the extra boilerplate.

But things really start to breakdown when a leaf feature suddenly needs access to a new dependency, like an API client:

 struct Feature4 {
+  let apiClient: APIClient
   let date: () -> Date
   init(
+    apiClient: APIClient, 
     @escaping date: () -> Date
   ) {
+    self.apiClient = apiClient
     self.date = date
   }
 }

That unfortunately reverberates throughout your entire app, forcing you to fix every feature that touches Feature4, and any feature that touches a feature that touches Feature4, and on and on and on:

 struct Feature1 {
+  let apiClient: APIClient
   let date: () -> Date
   init(
+    apiClient: APIClient, 
     @escaping date: () -> Date
   ) {
+    self.apiClient = apiClient
     self.date = date
   }

   func goToFeature2() {
     … = Feature2(
+      apiClient: apiClient,
       date: date
     )
   }
 }
 struct Feature2 {
+  let apiClient: APIClient
   let date: () -> Date
   init(
+    apiClient: APIClient, 
     @escaping date: () -> Date
   ) {
+    self.apiClient = apiClient
     self.date = date
   }

   func goToFeature3() {
     … = Feature3(
+      apiClient: apiClient,
       date: date
     )
   }
 }
 struct Feature4 {
+  let apiClient: APIClient
   let date: () -> Date
   init(
+    apiClient: APIClient, 
     @escaping date: () -> Date
   ) {
+    self.apiClient = apiClient
     self.date = date
   }

   func goToFeature4() {
     … = Feature4(
+      apiClient: apiClient,
       date: date
     )
   }
 }

This makes it incredibly difficult to add dependencies to features when they need them, and you may find yourself taking shortcuts because it is such a pain. Perhaps the most common shortcut is to use default values in initializers so that you are not forced to always pass along dependencies:

init(
  apiClient: APIClient = LiveAPIClient(), 
  @escaping date: () -> Date = { Date() }
) {
  self.apiClient = apiClient
  self.date = date
}

This now means you can do Feature1(), Feature2(), etc. without passing dependencies and they will use the live dependencies, and then in tests you can do Feature(apiClient: …, date: …) to provide a dependency that is suitable for testing.

However, this breaks down when testing the integration of features. If you were to follow this pattern, and try to write a test for Feature1 that involves running logic in Feature2, then Feature2 will be secretly using live dependencies even though you overrode the dependencies for Feature1 in the test. And that's because Feature1 did not pass along its dependencies to Feature2 and so they went back to the live version.

Compare all of this to just using @Dependency. A feature gets to declare what dependencies it needs in isolation:

struct Feature4 {
  @Dependency(\.apiClient) var apiClient 
  @Dependency(\.date) var date
  …
}

And if a feature doesn't use a dependency it does not need to declare it:

struct Feature1 {
  // No @Dependency if not needed
  …
}
struct Feature2 {
  // No @Dependency if not needed
  …
}
struct Feature3 {
  // No @Dependency if not needed
  …
}

And if a leaf feature needs to add a new dependency, it can do so without touching a single other feature in the app:

 struct Feature4 {
+  @Dependency(\.locationManager) var locationManager
   …
 }  

And further, in tests if a feature even so much as touches a @Dependency that is not overridden in the test you get a test failure. This forces you to be explicit with what dependencies are used while testing your features.

And this is really just scratching the surface. I recommend reading the various docs and articles in the repo, and I also gave a talk on this subject last year that you might be interested in.

[mbrandonw]

Hi @Pikuseru, I'm not sure I understand the question. Can you explain a bit more?

[Pikuseru]

Sure 🙂 I just wondered with the date example why I need to pass the date generator around like passing a parcel, and if I could pass something else to my feature that knows how to make the next feature, this then gives Feature 4 the date generator, then I don’t need to pass the parcel the date generator between features? Maybe something should be a block like:

Feature1 is given an @escaping () -> Feature2
Feature2 is given an @escaping () -> Feature3

And so on?

And then Feature4 can still be given the Date generator, but the other Features don’t need to know about the Date generator, all they know about is something that gives it the next feature?

[lukeredpath]

@Pikuseru what you're suggesting is the factory pattern and yes, this pattern can also be used to hide how a particular type is constructed from those that need to create them. It can help with the problem of introducing new dependencies but of course you now have to pass the factory around everywhere.

swift-dependencies uses an approach more akin to the service locator pattern, but one that is built on top of Swift concurrency's TaskLocals feature which makes it very powerful when it comes to overriding dependencies within a particular scope, rather than it just being a single global bag of dependencies.

There are pros and cons of pretty much every form of dependency injection solution out there, whether its initializer injection, property injection, service locators, factories etc. Its a debate as old as the concept of DI, so we're unlikely to reach a firm conclusion on what is "best", but from experience swift-dependencies works really well if you're using a single-point of entry architecture like TCA.

[mbrandonw]

Hi @Pikuseru, there's no better way to compare multiple approaches to a problem than to build the same thing multiple times, once for each approach. 🙂

We have a moderately complex app called SyncUps that was built using @Dependency. Perhaps you could fork it and then demonstrate the technique you are describing? That would help you see any pros/cons, and help me understand your idea.

[Pikuseru]

Thank you so much for replying and helping to explain things to me - very much appreciate it and the time you’ve spent making these awesome libraries 😊👍👏 I will have a go!

[Pikuseru]

I'm so impressed with TCA, thank you (and I understand the dependency now) 😄👍