How to use @Dependency for non-TCA Dependency Injection

Hey @stephencelis and @mbrandonw/ other interested folks,

I'm really excited about the new changes coming out in the protocol-beta branch. One of those is the Depencecy property wrapper. I've checked out the branch and am trying to use it for non-TCA DependencyInjection in my app. I know it wasn't the initial purpose of this property wrapper, as it's primarily for reducers' dependencies, but I think it would solve a number of DI issues we have in our app and I think it would be nice to get my dependencies in that form to prepare to use TCA.

I've been able to use it pretty easily with my existing vanilla Swift dependencies, however, I've run into two main issues and they're both pretty related to each other.

  1. I'm trying to change the depencency Context but because I'm not using a Reducer Protocol, I don't have access to the .dependency method, so I'm not really sure how to change the context.
  2. In addition to changing the context is there a way to provide other implementations to the DepencencyValues?

I finally found a way using the DependencyValues.withValues function to get an overriden version of the dependencies with a new context in the action closure. I'm not sure if that's the correct way to go and I'm wondering if there is anything a little more simple for tests, previews, etc.

Thanks in advance for the help.

Hi @BoldNotBald! While it might be possible to leverage this module outside of TCA use, we don't consider it a replacement for other dependency injection systems. We only really support a global default and scoped overrides that only last as long as the scope. This works well for reducers because they categorically have a single endpoint (reduce) that we can automatically instrument with scoped dependency injection. For more general purpose models and view controllers that that a bunch of ad hoc endpoints, this style doesn't really work.

However, if you're only needing to use a global bag of dependencies in your application, it should be generally usable, and you can use DependencyValues.withValues to override test dependencies. You can also rely on the default preview context to be set for previews. We don't automatically set the test context outside of the test store, but we could look into supporting that so you don't have to set this value yourself.

By the way, the GitHub discussions are a bit more active than our category here, so you may want to move the conversation (or future conversations) there!

1 Like

Awesome, thanks, Stephen. I'll take that into consideration. That's actually the direction I'm leaning at the moment to build out a different property wrapper that plays nicely with and can leverege our current DI solution. Thanks for the response! I'll go ahead and check out that other discussion.