A new approach to Container-Based Dependency Injection for Swift and SwiftUI.

Hey @hmlongco,

First of all would like to say well done on creating both Resolver and Factory. I have been using Resolver in production for over a year now and really happy on how much it helped us clean up our code in regards to dependency injection.

A pain point that we had with Resolver was when we migrated our code to the the new Concurrency model when using Mainactor or other types of Actors in general.

Now that Factory seems to be a full re-write of Resolver with new features in mind, I wonder if now is a good time for you (us?) to think a bit more on how to natively support concurrency out of the box. Looking at the code, the actor model should be able to help you a lot when it comes to thread safety.

Is this something that you're open to implement/discuss for Factory?

I love the simplicity of this DI package, but I'm finding the documentation a little confusing. My adoption of the package would depend on how it deals with a 'Clean Architecture' used in a professional workspace. Right now I'm struggling to understand how to use this package with a VIPER architecture. We use a similar structure to here: https://github.com/theswiftdev/tutorials/blob/master/VIPER/VIPERAndSwiftUI/VIPERAndSwiftUI/Sources/VIPER.swift

I began with this (below) but it doesn't compile (not even sure this is the correct approach):

import Foundation
import SwiftUI
import Factory

// MARK: - Router
typealias ListViewRouterInterface = any RouterInterface & ListViewRouterPresenterInterface

protocol ListViewRouterPresenterInterface: RouterPresenterInterface {
    func showDetails(for animal: Animal) -> any View
}

// MARK: - Presenter

typealias ListViewPresenterInterface = any PresenterInterface & ListViewPresenterRouterInterface & ListViewPresenterInteractorInterface & ListViewPresenterViewInterface

protocol ListViewPresenterRouterInterface: PresenterRouterInterface {

}

protocol ListViewPresenterInteractorInterface: PresenterInteractorInterface {
    func didLoad(animals: [Animal])
}

protocol ListViewPresenterViewInterface: PresenterViewInterface {
    var viewModel: ListViewModel? { get set }
    func onAppear()
    func onBtnPress(animal: String)
}

// MARK: - Interactor
typealias ListViewInteractorInterface = any InteractorInterface & ListViewInteractorPresenterInterface

protocol ListViewInteractorPresenterInterface: InteractorPresenterInterface {
    func fetchItems()
}

extension Container {
    static let apiService = Factory<APIServiceProtocol>(scope: .shared) { APIService() }
}

class ListViewContainer: SharedContainer {
    static let viewModel = Factory<ListViewModel>(scope: .shared) { ListViewModel() }
    static let presenter = Factory<ListViewPresenterInterface>(scope: .shared) { ListViewPresenter() }
    static let interactor = Factory<ListViewInteractorInterface>(scope: .shared) { ListViewInteractor() }
    static let router = Factory<ListViewRouterInterface>(scope: .shared) { ListViewRouter() }
}

final class ListViewModule {
    @Injected(ListViewContainer.viewModel) private var viewModel
    @Injected(ListViewContainer.presenter) private var presenter
    @Injected(ListViewContainer.interactor) private var interactor
    @Injected(ListViewContainer.router) private var router

    func build() -> some View {
        presenter.viewModel = self.viewModel
        let view = ListView(presenter: presenter)
        presenter.interactor = self.interactor
        presenter.router = self.router
        interactor.presenter = self.presenter
        router.presenter = self.presenter
        return view
    }

Do you have any advice on how to do this in a VIPER architecture? I think this would be a great example to add to your samples folder. The fact that VIPER has various Input and Output contracts make it difficult.

I have found a SIGABRT error occurs under a specific scenario. In this case, I am trying to provide a protocol for UIApplication, and I am setting this as a singleton (this is so that I can provide a mock during testing). The issue appears to be caused when setting the scope as singleton, and the factory itself is a singleton. I am providing the code here which causes the issue. All you need to do is run the test. FactoryDemo.zip

Hi Michael,

great to see another dependency injection library from you. I am a long time Resolver user and now questioning myself if it is possible to migrate from Resolver to Factory and how. I hope it is fine to ask some question about this in this format.

Currently Resolver is used in a MicroFeature architecture. So I have a lot of distinct features, all with an interface target and an implementation target. These features then are getting packed together in the final application target.

Each feature implementation only knows the interface of other features AND the Resolver framework. The application target in the end knows each features interface and each features implementation and registers appropriate implementations to the interfaces for other features to consume.

Some Code examples below. Feature A

// FeatureA interface

protocol FeatureAInterface {
    func fetchResourceA() async -> ResourceA
}

// FeatureA implementation

protocol FeatureAImplementation: FeatureAInterface {
    func fetchResourceA() async -> ResourceA {
        return ResourceA()
    }
}

Feature B

// FeatureB interface

protocol FeatureBInterface {
    func fetchResourceB() async -> ResourceB
}

// FeatureB implementation

final class FeatureBImplementation: FeatureBInterface {
    
    @Injected private var featureA: FeatureAInterface   
    
    func fetchResourceB() async -> ResourceA {
        let a = await featureA.fetchResourceA() 
        return ResourceB()
    }
}

App

import FeatureA
import FeatureAInterface

import FeatureB
import FeatureBInterface

register { FeatureAImplementation() }
    .implements(FeatureAInterface.self)

register { FeatureBImplementation() }
    .implements(FeatureBInterface.self)

When I now look at Factory I saw that it is now required to create an extension on Container to make services explicitly type safe available to consumers. Maybe I misunderstood the new library a little bit, but do you have some suggestion of how the behaviour I described will be working with Factory ? What I want to avoid is to expose the implementation of features to other features. Exposing implementations inside the place where everything is registered is fine though.

Maybe another question - will it also be possible to have a @OptionalInjected functionality again ? Maybe I oversaw it.

Thanks a lot in advance, and again thanks a lot for all your work so far !

Hey @hmlongco! I was thinking in a way to resolve a Factory passing a type something like that:

open class SharedContainer {

    public static func resolve<T>(scope: Scope) -> T? {
        resolveRegistration() ?? resolveScope(scope: scope)
    }
    
    static func resolveRegistration<T>() -> T? {
        let factories: [T] = Container.Registrations.registrations.compactMap { key, factory in
            guard let currentFactory: T = (SharedContainer.Registrations.factory(for: key) as? TypedFactory<Void, T>)?.factory(()) else {
                return nil
            }
            return currentFactory
        }
        return factories.first
    }
    
    static func resolveScope<T>(scope: Scope) -> T? {
        scope.cache.compactMap { id, factory in
            factory.instance as? T
        }.first
    }
 }

Do you think that this could be a way to do that? Or im not thinking in something?

First, thanks for releasing awesome DI library. 👍 I have one question. I thought as below, but this way seems to have some disadvantages of always having to specify the type as optional since it cannot give an initial value. If you have feature modules, what do you think is the best way to inject dependencies into each module?

In a feature module,

class AFeatureContainer: SharedContainer {
    static let optionalService = Factory<ServiceType?> { nil }
}

In a main module,

AFeatureContainer.optionalService.register { Service() }

First of all, I would like to thank for this library. It's exactly what we were looking for.

I was wondering why Factory does not have built-in GraphScope. I know that Resolver had that kind of functionality so I am wondering about reasons why it's not included here. I think it's possible implement it in this way:

func mapInGraph<T>(_ resolve: (GraphIdentifier) -> T) -> T {
            // Will create new graph id if it is the root
            // Otherwise it will use graphID from parent graph
            let isRoot: Bool = Self.graphID == nil
            let graphID = Self.graphID ?? UUID()

            if isRoot {
                Self.graphID = graphID
            }

            // Resolve instance
            let instance = resolve(graphID)

            if isRoot {
                // reset graph ID when exiting the graph
                Self.graphID = nil
            }
            return instance
        }

cache would be then per graph:

private var cache: [GraphIdentifier: [Identifier: any Box]] = .init(minimumCapacity: 64)

and then resolve function has to be changed:

func resolve<T>(id: Identifier, factory: () -> T) -> T {
            defer { lock.unlock() }
            lock.lock()

            return mapInGraph { graphID in
                /// retrieve from cache based on graphID
                /// ...

                /// if not find in cache create new instance and store in cache based on grapID
                /// ...
            }
        }

There's some trickery that needs to be implemented because of multithreading but this is the basic concept. Do you see any problem with it?

Hello, I've used Resolver for a while and just switched over to Factory. Both libraries help to circumvent common issues with EnvironmentObject, but both libraries also run into the same issue wherein you lose the ability to trigger SwiftUI views to update when a property on the object changes by default. This usually requires a bunch of boilerplate code and a required ViewModel, so there's easy way to make lightweight views the way one might with EnvironmentObject, which creates an inverse problem to the one presented by SwiftUI's EnvironmentObject.

Curious what the expectation is for working around this, or if there are plans for something like an @InjectedObject (as in Resolver) property to help account for this? I saw issue #1, but it doesn't really go into detail, and the provided snippet doesn't actually support re-rendering views (see example below), so it's not really a valid workaround for achieving the same behavior by itself.

This library seems like an extremely easy-to-use and easy-to-onboard dependency injection tool, but I would argue it's not really SwiftUI-compatible (or at least not SwiftUI-optimized) without functionality like this in place, and/or some comprehensive documentation in the README for what the expectations/workarounds are for dealing with this.

Problem

Say we want to pull AppSettings into a view, which is just a struct that has an environment property. Ideally, this would be all it takes to achieve that:

struct MyView: View {
    @Injected(Container.appSettings) var appSettings

    var body: some View {
        Text(self.appSettings.environment)
    }
}

However, when appSettings.environment is updated, the view does not reload -- which is a known limitation of this library.

If I take the snippet provided in issue #1, it doesn't resolve the problem -- the view still doesn't reload.

struct MyView: View {
    @StateObject var viewModel = MyViewModel()

    var body: some View {
        Text(self.viewModel.appSettings.environment)
    }
}

final class MyViewModel: ObservableObject {
    @Injected(Container.appSettings) var appSettings
}

Instead, I have to do something like this:

final class MyViewModel: ObservableObject {
    @Injected(Container.appSettings) var appSettings

    private var subscriptions = Set<AnyCancellable>()
    
    init() {
        // without this block, MyView will not trigger a state refresh.
        self.appSettings.objectWillChange.sink { _ in
            self.objectWillChange.send()
        }
        .store(in: &self.subscriptions)
    }
}

or this

final class MyViewModel: ObservableObject {
    @Injected(Container.appSettings) var appSettings
    @Published var environment: Environment

    private var subscriptions = Set<AnyCancellable>()
    
    init() {
        // no different than the example above unless I optimize further
        self.appSettings.$environment
            .assign(to: &self.$environment)
    }
}

Proposed Solution

A reimplementation of Resolver.InjectedObject to be included in this library:

@propertyWrapper public struct InjectedObject<T>: DynamicProperty where T: ObservableObject {
    @ObservedObject private var dependency: T
    
    public init(_ factory: Factory<T>) {
        self.dependency = factory()
    }
    
    public var wrappedValue: T {
        get { return dependency }
        mutating set { dependency = newValue }
    }
    
    public var projectedValue: ObservedObject<T>.Wrapper {
        return self.$dependency
    }
}

I don't think we need to provide an implementation for StateObject explicitly since we're not worried about a view being the owner of the StateObject -- similar to how there is no EnvironmentStateObject and EnvironmentObservedObject, for example.

That said, if we needed to (or it would help optimize or anything), we could also add InjectedStateObject for explicit conformance.

Hello,

I read the other ticket about the register issue but it didn't help me and mine is a little bit different.

The register method doesn't work ONLY during the TestUnit

Here my situation:

---- Container ----

class CustomContainer: SharedContainer {
        static let poc = Factory<String>(scope: .singleton) {
            "Initial project"
        }
}

---- ViewModel ----

final class ViewModelPoc {
    @LazyInjected(CustomContainer.poc) private var poc

    func unitTestMethod() {
        print("Result: \(poc)")
    }
}

---- Test Unit ----

class SimpleTests: XCTestCase {

    override func setUp() {
        super.setUp()
        CustomContainer.poc.register { "Test project" }
    }

    func testMethod() {
        ViewModelPoc().unitTestMethod()
    }
}

And when I run the test the consol display "Result: Initial project"

If you have any suggestions ? Thanks

func authenticated(with user: User) {
    ...
    Container.userProviding.register { UserProvider(user: user) }
    ...
}

In the above example that you provide, what was the way that userProviding was initially registered? Should this be created as a nilable, a UserProvider that takes no user, or even a separate type conforming to UserProviding protocol?

Hi, I am not able to wrap my head around how to best use Factory in a multi-project setup, formed around a clean architecture pattern. This was easy with Resolver, but in Factory it seems to lead to circular references - unless you accept a "doubling" of references.

Consider the following architecture in an XCWorkspace:

App (contains the SwiftUI project with views and viewmodels) Core (framework that contains the protocols and models) Services (framework that contains the services, for example external api integrations) Bootstrap (framework that bootstraps Services and Core for dependency injection/ioc)

In Factory, registrations made in Bootstrap will not be visible to App or Services.

In a clean architecture using xcworkspace, separation is the key benefit. App should not know about the concrete implementations of the services, it will only operate on the protocols. Therefore, App does not have a reference to Services, only to Core where the protocols live. And because of that, a separate project needs to do the bootstrapping, ie Bootstrap.

My Bootstrap project contains only this, and embeds the Core and Services projects to make this work:

extension SharedContainer { static let httpClient = Factory(scope: .singleton) { HttpClient() as HttpClientProtocol } static let linksService = Factory(scope: .singleton) { LinksService() as LinksServiceProtocol } }

My App project embeds the Bootstrap project and the Core project

My Services project embeds Core.

Services needs an instance of HttpClientProtocol: @Injected(Container.httpClient) private var httpClient: HttpClientProtocol

But that will not work, since the registration is done in Bootstrap. Services has no notion of Bootstrap at all.

Is there a way with Factory? If not, the Inversion of Control part of Dependency Injection is missing in this framework, and it will only work for monolith projects.