Question about leaking dependencies

[WedgeSparda]

Hi, at our dev team we're exploring the possibility to use the dependencies library in order to replace our DI system.
Right now we're using big types (Composition Roots) creating all repositories and use cases and generating the presenters and views (we're using SwiftUI and UIKit since is a project with a long history).

Using those Composition Roots we create a model tree where we lazy implement what we need just in time. But there is an scenario where part of that tree needs to be recreated completely.

Since @dependency lives staticly, once is created there is no need to create it again and that works for almost all possible scenarios. But let's say one of those dependencies is a use case with a timer, geolocation listener or another recurrent work. Once the dependency is created, that work will continue forever.

I've created this silly project example to show what I mean. Project is presenting a modal which uses two use cases as dependencies.

• StartTimer: Uses a timer to generate a random number each second and publishes into a PassthroughSubject
• SubscribeToTimer: Listen to StartTimer PassthroughSubject and nothing else

After swipping down the modal to dismiss it, SubscribeToTimer is removed from memory (but I see is still part of DependencyValues) but StartTimer is not. I'm guessing the reason behind this problem is the timer but wanted to ask in order to confirm my suspicious.

If this is the case, I'm guessing the only possible solution would be to add extra logic to the use case to check if there is stop and dealocate the timer in case there is no longer subscriptions listening, right?

Sorry if this questions sound a bit silly? Still getting my head around this amazing library.

Thanks for your time and amazing job with Dependencies.

[mbrandonw]

Hi @WedgeSparda, are you sure you pushed the final commit to your sample repo? It seems to be a blank project right now.

Also I'm not familiar with the term "Composition Root". Do you have some references for that?

[WedgeSparda]

Hi @mbrandonw , sorry for the confusion, project is commited correctly now.

About the "Composition Root", they're just big classes in charge of create all the types used by a domain. For example:

final class AppCompostitionRoot {

    private var userCompositionRoot = UserCompositionRoot()
    // ... more composition roots

    func getAwesomeUseCase() -> AwesomeUseCase {
        AwesomeUseCase(
            anotherAwesomeUseCase: userCompositionRoot.getAnotherAwesomeUseCase()
        }
    }

    // ... more Use Cases initializers

    func getAwesomeViewController() -> AwesomeViewController {
        AwesomeViewController(awesomeUseCase: getAwesomeUseCase())
    }
}

Simply put is a very primitive way to create all the types we use in our project, but as you can imagine is pretty hard to maintain since each parameter change needs to be modified in several parts of our code. That's the main reason we're exploring the possibility of using @Dependency to inject all the use cases directly where they're needed.

I hope this helps to clarify my point.

Thanks.

[mbrandonw]

Great, thanks for the code sample, that helps a lot to understand what it is you are trying to go for.

I believe to best leverage this library you may need to rethink what you consider a "dependency". In the example you gave you have packaged up a lot of logic into a StartTimerUseCase dependency. As far as I can tell, it encapsulates a full unit of logic for a feature.

That's not really the use case for this library. This library recommends modeling dependencies as small atomic units that has a specific interaction with the outside world (e.g. a scheduler, an API client, etc...), and then you use those dependencies to implement your feature's larger, more complex logic.

So, in your situation, it would be better to instead think of your dependency as just the timer, and then to move the logic that interacts with the timer to your feature. You could even use the @Dependency(\.mainQueue) or @Dependency(\.continuousClock) that comes with the library in ModalViewController, and then subscribe to the timer in those features and tear down the effect when the feature goes away.

There are a lot of benefits to this. First off all, you get to implement your features in the most natural way possible. You can just interact with the dependency right in the view controller / observable object like you would before you cared about controlling dependencies, but with the added benefit that you can actually test the logic now.

Second, you get to test more of your feature. Right now to test your modal feature you would mock out the entirety of StartTimerUseCase, which means none of the logic inside the liveValue gets exercised. If instead you only depend on a clock and move the logic to the modal feature, then you get to test everything.

So, as a general rule-of-thumb, the simpler your dependencies are inside the liveValue the better. And it's ok to use multiple dependencies in your feature and then glue them together at the feature level so that you can test all of that integration.

But, that rule isn't universal. There may be times it is ok to have a little logic in the live value if it truly doesn't need representation directly in your feature. One example that comes to mind is an analytics client that archives any events that failed to send to the backend so that it can try again later. You can technically hide away those details in the liveValue, and if done properly you can still test just that behavior in isolation.

Hope that helps.

[WedgeSparda]

Hello @mbrandonw thanks for your answer.

What you said is what I was afraid of. So is something we need to deeply discuss before changing our dependencies to this system.

Just to double check. If our Use Cases would be stateless, meaning that they don't store any data and act only as, let's say pipelines, to transform some input into some output, then using @dependency should be completely safe, correct?

[mbrandonw]

Just to double check. If our Use Cases would be stateless, meaning that they don't store any data and act only as, let's say pipelines, to transform some input into some output, then using @dependency should be completely safe, correct?

Overall I think that is correct, but it's hard to say for sure without seeing some actual code of what you mean by "pipelines."