Using Dependency outside of TCA (in Previews)

[rrozenv]

I know the primary use case for Dependency is in TCA, but I'm wondering if it's currently possible to use outside of TCA.

My goal is to be able to easily override certain dependencies for a class instance like FeatureModel. For example, to generate a preview for FeatureView which depends on FeatureModel I'd like to do something like this:

struct Preview: PreviewProvider {
  static var previews: some View {
    DependencyValues.withValues {
      $0.date = .constant(Date(timeIntervalSince1970: 1234567890))
    } operation: {
      return FeatureView(model: FeatureModel())
    }
  }
}

Obviously this doesn't work as the overridden dependency only lives for the scope of operation (also the compiler has trouble interpreting this sort of code).

I also attempted to more crudely just overwrite the global dependency through DependencyValues._current:

struct Preview: PreviewProvider {
  static var previews: some View {
    DependencyValues._current.date =  .constant(Date(timeIntervalSince1970: 1234567890))
    return FeatureView(model: FeatureModel())
  }
}

This doesn't work either as '_current' is a get-only property.

Having the ability to modify _current seems like a potential solution for this specific use case but could of course have many unintended consequences. So I'm wondering if anyone has any ideas on how to get something like this to work?

Thanks in advance!

*The issue I'm describing is similar to the one noted here: #1533 but the use case I'm describing has some key differences

[iampatbrown]

Hey @rrozenv,

I believe the plan is to seperate Dependencies into a standalone library i.e. swift-dependencies. I'm pretty sure something like you're describing would be supported.

There are probably a few ways to achieve this at the moment though. One that I've used before is to create a property wrapper that wraps around Dependency that accesses shared DependencyValues Here's an example:

@propertyWrapper
public struct SharedDependency<Value>: Sendable {
  @Dependency private var value: Value

  public init(
    _ keyPath: KeyPath<DependencyValues, Value>,
    file: StaticString = #file,
    fileID: StaticString = #fileID,
    line: UInt = #line
  ) {
    self._value = Dependency(keyPath, file: file, fileID: fileID, line: line)
  }

  public var wrappedValue: Value {
    DependencyValues.withValue(\.self, DependencyValues.shared) { self.value }
  }
}

And the shared values could look something like this:

extension DependencyValues {
  private static let lock = NSRecursiveLock()
  private static var _shared = DependencyValues()

  public static var shared: DependencyValues {
    _read {
      Self.lock.lock()
      defer { Self.lock.unlock() }
      yield Self._shared
    }
    _modify {
      Self.lock.lock()
      defer { Self.lock.unlock() }
      yield &Self._shared
    }
  }
}

This isn't what I use at the moment so I haven't really double checked the above. It's just similar to what I used to do.

You can also add an extension to Dependency to show a warning if the non shared version is used.

extension Dependency {
  @available(*, deprecated, message: "Use SharedDependency until swift-dependencies is released")
  public init(_ keyPath: KeyPath<DependencyValues, Value>) {
    self.init(keyPath, file: #file, fileID: #fileID, line: #line)
  }
}

[rrozenv]

Thanks @iampatbrown! This makes sense.

As more of a theoretical question - do you see the library supporting a use case where you can override dependencies for a specific instance of a class when initializing it? For example:

func createHostingController() -> UIHostingController { 
    DependencyValues.withValues {
      $0.date = .constant(Date(timeIntervalSince1970: 1234567890))
    } operation: {
      // Using `@Dependency(\.date) var date` within the `FeatureModel` would use the new `date` value set within `DependencyValues.withValues`
      let model = FeatureModel()
      let view = FeatureView(model: model)
      return UIHostingController(rootView: view)
    }
}

Given the design of the current API and how it's used in TCA it's hard to envision that something like this could be possible (hence why using TCA is a good idea), but could you see the standalone library potentially handling such a use case?

[iampatbrown]

do you see the library supporting a use case where you can override dependencies for a specific instance of a class when initializing it?

If your only requirement is for the model to be initialized with a specific dependency and store it, then yes. That is sort of possible now. eg.

class FeatureModel {
  let date: DateGenerator
  init() {
    self.date = DependencyValues._current.date
  }
}

or if you wanted a property wrapper you could do something like:

@propertyWrapper
public struct StoredDependency<Value> {
  public let wrappedValue: Value

  public init(
    _ keyPath: KeyPath<DependencyValues, Value>,
    file: StaticString = #file,
    fileID: StaticString = #fileID,
    line: UInt = #line
  ) {
    self.wrappedValue = Dependency(keyPath, file: file, fileID: fileID, line: line).wrappedValue
  }
}

extension StoredDependency: Sendable where Value: Sendable {}

If you wanted nested child models to inherit dependencies from parent models then it would require a bit more work, but could most likely be done with a standalone library that used swift-dependencies as a base.

[mbrandonw]

Given the design of the current API and how it's used in TCA it's hard to envision that something like this could be possible (hence why using TCA is a good idea), but could you see the standalone library potentially handling such a use case?

The exact use case you have sketched actually is possible with a little bit of work in the library, but the problem is that it breaks down quickly for more complicated things. While FeatureModel will get its date dependency from what was set in DependencyValues.withValues, if FeatureModel creates a child model, then that model will go back to using the default dependency values.

We need to come up with an API that allows extending the scope of the dependencies for longer. We just haven't had time to explore that yet.

[rrozenv]

Thanks @iampatbrown and @mbrandonw! I'll stick with the solution SharedDependency for now, that should be good enough for most of my use cases.

Just a note on StoredDependency - this only works if the dependency is a value type. I know the recommendation is to generally stick with value types for dependencies, but this doesn't always play super nicely outside of TCA especially when dependencies wrap 3rd party libs (since those wrappers often need to manage some internal state).

If you ever get around to exploring solutions that extend the scope of dependencies, it would be good to keep in mind that dependencies may also be reference types.

Thanks for taking the time to answer and for all your work on such amazing libraries, it's greatly appreciated!