Factory 2.0 available in develop

[hmlongco]

As mentioned earlier, Factory 2.0 is under development and will be released shortly. If you're brave, or just curious, you can access the develop branch today and check it out.

• Adds true Factory containers for container-based dependency resolution
• Adds container-based scopes
• Adds decorators to containers and factories
• Adds debug trace support

At the moment it passes all of the existing unit test and feels pretty solid, so it should be relatively safe to play with. Keep in mind that it's a breaking change from 1.0, so make sure to read the README.

There's a lot of DocC documentation available, with more coming, so stay tuned.

[hmlongco]

Here's a Factory 2.0 definition.

extension Container {
    var simpleService1: Factory<SimpleService> {
        self { SimpleService() }
    }
}

We define the computed variable on our container, and then use a bit of syntactic sugar to ask the container to create our Factory for us.

[rsaccone]

Hi,

Any thoughts as to when you think 2.0 might be released? Just looking to get some sort of feel as I am going to propose that we adopt Factory for a couple of projects at work and I want to do some prototyping to make the case.

Thanks

[hmlongco]

It's functionally complete now. The only thing left really is deciding on the "helper" syntax. So probably will push it out in a week or two.

[rsaccone]

Thanks for the reply. Sounds good.

[rsaccone]

I have an object that provides two different protocols and I am having difficulty getting it to work correctly with the graph scope. The underlying object itself should be a singleton so I thought the correct way to register it would be use the singleton scope modifier followed by the graph scope modifier. What I am finding at runtime though is that multiple instances of the object are being created when it is being accessed (through the injected property wrapper). Here's a snippet showing the setup. Any thoughts as to what I might be doing wrong here:

extension SharedContainer {
    var appStateEventPublisherProvider: Factory<AppStateEventPublisherProvider> {
        self { self.appStateEventService() }
    }

    var appStateEventDispatcher: Factory<AppStateEventDispatcher> {
        self { self.appStateEventService() }
    }

    private var appStateEventService: Factory<AppStateEventService> {
        self { AppStateEventService() }.singleton.graph
    }
}

The AppStateEventService is the underlying object. I followed the example in the doc but the difference here is I need the instance to be a singleton.

If I remove the graph scope and just leave singleton then I get the behavior I want. This is similar to how I accomplished a singleton object that returns multiple protocols in Factory 1.0. Just thought that with 2.0 I should somehow be putting the graph scope to use in this scenario. Any details you can provide on this are appreciated.

Thx
Rob

[hmlongco]

I explained that in the docs when discussing graph. https://hmlongco.github.io/Factory/documentation/factory/scopes

There has to be a root to the graph that Factory is asked to resolve. If you just do...

class SomeClass {
    @Injected(\.appStateEventPublisherProvider) var appStateEventPublisherProvider
    @Injected(\.appStateEventDispatcher) var appStateEventDispatcher
}

let s = SomeClass()

Then the appStateEventPublisherProvider will ask its factory for its value and then it will be done. Then appStateEventDispatcher will ask its factory for its value and then it will be done.

Those are two different, separate, and distinct resolution cycles. And graph has no effect. If, however, you did...

let s = Container.shared.someClass()

Then graph would work because everything is happening within a single resolution cycle.

[rsaccone]

Ah I see I missed the point that the consumer (SomeClass in your example) also needs to be instantiated by factory. In my app the appStateEventPublisherProvider and the appStateEventDispatcher aren't being used in the same entity and they aren't being created via Factory. The appStateEventPublisherProvider is being used in SwiftUI Views to set up onReceive handlers because it vends the publisher. The appStateEventDispatcher is used in the ExtensionDelegate that wants to publish the app state events. As I mentioned a single object is implementing both of these protocols and the same object needs to be returned to both the SwiftUI View and the ExtensionDelegate. I guess this isn't the use case that graph is intended for.

[hmlongco]

Nope. Singleton. Or you could even use shared if you want it to go away when no one is using it.

[hmlongco]

I explained that in a lot more detail here...

https://hmlongco.github.io/Factory/documentation/factory/cycle/