Is it possible to use new instance whenever we need to use liveValue?

[HotFryingPan]

Hi I'm currently trying to pick & choose what DI framework that suits me because I'm still using the factory method as my DI ( you guys must be familiar with this 🤣).
It's interesting that this library is looking to SwiftUI Environment, but since most of my codebase is still UIKit, so I'm looking to how I could use this on my project. And this library can produce error when we're not using testValue to inject the data so that's a big + for my needs.

And here's where I'm coming from on my new project:

1. When I call my factory method, I always get the new instance. Singleton is very rarely used & it's needed in a couple of use cases
2. Very hard to maintain because the factory method is scattered all over the place
3. Might have issues with undetected circular dependency later on

// My current situation
// ViewModel
class ViewModel { 
   private let getFilm: GetFilm // GetFilm is a protocol & has private GetFilmImpl as the implementation detail
   init(getFilm: GetFilm) { 
    self.getFilm = getFilm
   }
}

// factory method
extension ViewModel {
static func makeViewModel() -> ViewModel {
    return ViewModel(
      getFilm: GetFilm.makeGetFilm() // make new GetFilm instance
    )
}

extension GetFilm {
static func makeGetFilm() -> GetFilm { 
// make concrete GetImpl here with the same `ClassName.makeClassName()` pattern.
    return GetFilmImpl(services: ...)
}


// what it looks like to inject the vm
class FilmVC: ... {
   private let viewModel = ViewModel.makeViewModel() // make new ViewModel instance
}

Finally here's my questions:

1. Does this library only structured to be used on the composable architecture / single entry point?

• I asked this is because there's some caveat in the documentation about this so I think when this library is created, the design is only focused on those 2 things? 🤔

2. Why we prefer to use static let instead of lazy var for the liveValue & the other value? Is there a way to make a new instance everytime I need the dependency?

• I ask this because I wonder why we're using singleton as the default lifetime scope.
• I want to replicate the behavior of my factory method so I want a new instance everytime I need a dependency.

3. Follow up from No.2, if we're using static let, when I have a lot of dependencies, does it mean we keep all of that property in the memory until the app closed or the library have a way to clean it up from the memory when it's not needed?

• Asking this because I need to make sure I only use what I need & clean it up afterwards. I think it's alright to keep a way to make the instance rather than keeping the instance.

4. Any example on how we should use this library on multi-module apps?

• I want to know how to spread the registration closure across the modules & how can I assemble all of that in the main module.

I'm sorry for my long chat 🙇
Very appreciated to have a discussion with you guys.

[stephencelis]

Finally here's my questions:

1. Does this library only structured to be used on the composable architecture / single entry point?

• I asked this is because there's some caveat in the documentation about this so I think when this library is created, the design is only focused on those 2 things? 🤔

While the library shines in single entry point, it is for sure compatible with non-single entry point 😄 See this section of the documentation: https://swiftpackageindex.com/pointfreeco/swift-dependencies/main/documentation/dependencies/singleentrypointsystems#Non-single-entry-point-systems

2. Why we prefer to use static let instead of lazy var for the liveValue & the other value? Is there a way to make a new instance everytime I need the dependency?

• I ask this because I wonder why we're using singleton as the default lifetime scope.
• I want to replicate the behavior of my factory method so I want a new instance everytime I need a dependency.

In Swift static let is resolved lazily already (it's basically like dispatch_once). Generally, DependencyKey is a description of a static/singleton dependency. If you want to create instances of some dependency more dynamically, you can implement a method on the static dependency that vends some instance.

struct MyDependency {
  var create: () -> MyInstance
}

// Or using a protocol, if you prefer:
protocol MyDependency {
  func create() -> MyInstance
}

3. Follow up from No.2, if we're using static let, when I have a lot of dependencies, does it mean we keep all of that property in the memory until the app closed or the library have a way to clean it up from the memory when it's not needed?

• Asking this because I need to make sure I only use what I need & clean it up afterwards. I think it's alright to keep a way to make the instance rather than keeping the instance.

Again, we should consider these statics as interfaces that live as long as your application lives. Because the space is static it should also be relatively small, so there shouldn't be any worry about memory here, just like you shouldn't worry about NotificationCenter.default hanging around forever.

If you have lifecycle-based dependencies that are introduced by some kind of create() interface as sketched above in the previous point, those instances will be reclaimed whenever they go out of scope.

4. Any example on how we should use this library on multi-module apps?

• I want to know how to spread the registration closure across the modules & how can I assemble all of that in the main module.

See this part of the docs: https://swiftpackageindex.com/pointfreeco/swift-dependencies/main/documentation/dependencies/livepreviewtest#Separating-interface-and-implementation

[HotFryingPan]

Thanks for answering my questions @stephencelis.

In Swift static let is resolved lazily already (it's basically like dispatch_once). Generally, DependencyKey is a description of a static/singleton dependency. If you want to create instances of some dependency more dynamically, you can implement a method on the static dependency that vends some instance.

Is there any possibilities we can keep creating new instance using create() method but still initialized it using the property wrapper?

@Dependency(MyDependency.self)var my dependency

And I have 1 more question. What’s the reason to make everything singleton as default behavior?

Because I can’t get the reason the needs to encourage the user to only manage 1 instance for the whole app lifetime.

I was thinking I can keep creating new instance when using it like this but I’m not sure is this the correct approach/not.

static var liveValue: MyDependency {
  MyDependency() // i was thinking this will always make new instance every time liveValue gets called
}