Dependencies that require runtime data to be initialised.

[sergdort]

Hey guys! Thanks for your hard work!

I'm researching of ways to migrate from TCA Environment based dependencies to the new solution. And in many places of our app we have services that need runtime data to be usable. For example we've got a UserConfigService that needs UserData that we get from our server after successful sign in e.g

final class UserConfigService {
    private let userData: UserData
    
    init(userData: UserData) {}
}

Is there a more elegant solution that you would suggest? Because mine looks something like

extension UserConfigService: DependencyKey {
    public static var _liveValue: UserConfigService!
    
    public static var liveValue: UserConfigService {
        return _liveValue
    }
}

or

final class UserConfigService {
    private let userData: UserData?
    
    init() {}

   func update(with userData: UserData) {}
}

I've seen in other treads people suggested to use nested Dependency wrappers like:

final class UserConfigService {
    @Dependency(\.userData)
    private var userData
    
    init() {}
}

Would love to hear your thoughts on that!

[mbrandonw]

Hi @sergdort, using @Dependency is definitely fine to use from other dependencies. We plan on writing more documentation about this.

I will also say that the other two styles you have sketched out are not recommended. The first, the one that uses the implicitly unwrapped optional, will not work because upon first access of a dependency it is cached. So you run the risk of caching the nil value. And the second can just be annoying to use in practice since you may forget to call update(with:) and you have to deal with an optional.

[sergdort]

Thanks, @mbrandonw ! Would it be correct to set a service in a runtime via DependencyValues then?

DependencyValues.live.userSessionServices = UserSessionService(userData: userData)

[sergdort]

Thanks! I see, so dependencies do not share the "Store" scope, but have a global resolution mechanism 👍

[mbrandonw]

I'm not sure what you mean by share the "Store" scope, but you are correct that by default all access to @Dependency goes through a "global" cache mechanism. I put global in quotes because it is very easy to detach from that cache to have a completely new cache:

withDependencies {
  $0 = DependencyValues()
} operation: {
  FeatureModel()
}

That will cause the FeatureModel to run in a context where no dependencies are cached and everything is reset back to its defaults.

[sergdort]

I guess by Store scope I mean that if we apply dependency method to a reducer e.g

let store = Store(initialState: state, reducer: MyReducer().dependency(\.myDependency, dependency))

Then MyReducer and any its children will inherit the value of the dependency, while it does not seem to be the case. Like in my mind I was thinking that once we do that a new instance of DependencyValues created (with a new cache instance etc) which is associated with this Store instance.

[mbrandonw]

I think the reason that things are that way is because typically you only create one single store at the root of the application, and then derive new stores via store.scope. In that set up it doesn't matter if you clear the cache or not.

However, we do want to explore more into what it means to have multiple, disconnected stores in an application, and maybe when we get deep into that we will change our mind about the behavior. Maybe whenever you construct a store directly (as opposed to via scope) it should clear the dependency cache automatically. Or maybe there's some kind of Store.detach operator (just spitballing).

But until then you can accomplish what you want like this:

Store(
  initialState: …
  reducer: AppReducer()
    .dependency(\.self, DependencyValues())
    .dependency(…)

That will clear the cache for just this one store.

And once we make the newest TCA release (0.50) you will just be able to supply a trailing closure to Store to customize the dependencies:

Store(…) {
  $0 = DependencyValues()
  $0.myDependency = …
}

[sergdort]

Thanks @mbrandonw.
We do use multiple stores in our app as we had some performance issues and Swift limitations. But yeah even with this setup we don't want these stores to use different dependencies at runtime.
It was more like an exercise for me to figure out the Dependencies lifetime =)