FactoryKit Migration

[hmlongco]

Factory is moving to version 2.5.0 that works with SPM, Xcode 16 under Strict Concurrency guidelines, and with Swift Testing.

If you're a current Factory user it's recommended that you switch from importing Factory to FactoryKit.

This name change avoids SPM naming conflicts between the import library name and the primary Factory object, and should fix a number of open issues with the project.

To do so, open your project in Xcode and...

1. Select File > Packages > Update to Latest Package Versions
2. Select File > Packages > Reset Package Caches
3. Go to your application target, remove the Factory library, and add the FactoryKit library
4. Go a global search and replace, renaming import Factory to import FactoryKit
5. Clean and build your project.

You may need to do the same for any other targets or modules that imported Factory.

While the original Factory library import still exists, it will be deprecated in the future.

This code is currently in the develop branch of the project.

Note that the FactoryKit and FactoryTesting library changes are for SPM only. CocoaPods will be frozen to a 2.4.x version in the near future.

[hmlongco]

Also added in 2.5.0.

ParameterFactory Scopes

By default, ParameterFactory scopes will cache the first requested value and then return the service created with that value, even if other values are passed on future requests.

The behavior can be changed with the .scopeOnParameters modifier.

var parameterService: ParameterFactory<Int, ParameterService> {
self { ParameterService(value: $0) }.scopeOnParameters.cached
}
The passed parameter must be Hashable for this modifier to appear and for the per-parameter caching functionality to occur.

That code is in the develop branch as part of 2.5.0.

[danielepantaleone]

Hi, I have a question on this matter. Is the ParameterFactory behaviour changed with respect to Factory 2.4.*? If I recall correctly, ParameterFactory caching was not supported and every request to a ParameterFactory was returning a new instance (prior to scopeOnParameters).

I'm asking this because I'm making heavy use of ParameterFactory in a SDK I'm maintaining and usually I have parameters that are not Hashable and cannot conform to Hashable, e.g:

var bleCentralManager: ParameterFactory<(
    delegate: BleCentralManagerDelegate?,
    queue: DispatchQueue?,
    options: [String: Any]?
), BleCentralManager> {
    self {
        CBCentralManager(
            delegate: $0.delegate,
            queue: $0.queue,
            options: $0.options)
    }
    .onPreview { _ in MockBleCentralManager() }
    .onSimulator { _ in MockBleCentralManager(state: .poweredOn) }
    .onTest { _ in MockBleCentralManager() }
    .unique
}

I managed to configure Factory 2.5.0 and rename all imports to FactoryKit but all of a sudden 80% of all my SDK tests were failing. Reverting to Factory 2.4.13, which also has support for ParameterFactory caching solves the issue (so probably the issue is somewhere else but looking at the diff between 2.4.13 and 2.5.0 I couldn't find anything that can break my unit tests though).

[hmlongco]

Scope caches are dictionaries at heart and keys need to be hashable/equatable. If I had to do the above I'd probably create a parameter structure I could name for individual cached returns, with the name being the hash key.

struct BleCentralManagerParameters: Hashable {

    let name: String
    let delegate: BleCentralManagerDelegate?
    let queue: DispatchQueue?
    let options: [String: Any]

    func hash(into hasher: inout Hasher) {
        hasher.combine(name)
    }

    static func == (lhs: BleCentralManagerParameters, rhs: BleCentralManagerParameters) -> Bool {
        lhs.name == rhs.name
    }
    
}

As to switching, it was pretty simple for me. Make sure you remove Factory from the main project and import the FactoryKit library instead.

Do not add the FactoryKit library to the test target. That will cause problems and errors. Only add FactoryTesting to the test target, if desired.

If you figure out what's wrong and find there's something else that needs to be done in the migration, let me know and I'll add it to the docs.

[danielepantaleone]

Hi, sorry for the late reply but I have been on Holidays.

That doesn't fully answer my question. In your comment you mention:

By default, ParameterFactory scopes will cache the first requested value and then return the service created with that value, even if other values are passed on future requests.

I presume that this is true if an only if the ParameterFactory parameter is Hashable, hence the resolved dependency can be cached into a dictionary indexed under the key obtained from the Hashable parameter.

If instead ParameterFactory scopes will now cache (somehow) the first requested value even if the ParameterFactory parameter is not Hashable, hence scopeOnParameters is not available, then the behaviour changed with respect to Factory 2.4.x. (which is exactly what I am experiencing).

For instance, in my unit tests I have 4 instances of BleConnection that I create at unit test start. When I execute the factory below on Factory 2.4.x I have the expected 4 instances, while if I run the same code under Factory 2.5 I get only 1 instance and the factory closure is called just once.

I'll give a try to your suggestion though, so I can set unique scope on the ParameterFactory.

[danielepantaleone]

As expected, by using BleConnectionParameters (which conform to Hashable) and setting scopeOnParameters.unique restore the old behaviour. I'll now have to apply the same change to all ParameterFactory in my container, but I'm glad it's sorted out 😃.

[hmlongco]

Correction, Factory has moved to 2.5.0 and is now in production.