Comments (9)
That one's tough.
What you're currently doing is what Resolver does. Basically the code is hoping that someone, somewhere, has registered a factory to provide an instance of the needed interface.
Factory, on the other hand, works by ensuring that there's an implementation to be seen, hence it's compile-time safe. It doesn't hope. It knows.
I'll have to think about that one a bit.
from factory.
Thanks a lot for thinking about it. I was also wondering if the approach described by me will even be possible with Factory
. Because it is exactly what you said.
The features just rely on, that there will be some implementation conforming to the given protocol. They have no guarantee however and the application will crash if a developer has forgotten to add a certain dependency.
from factory.
Still thinking, but one option might be something like this...
protocol FeatureAInterface {
...
}
extension Container {
static var featureA = Factory<FeatureAInterface?> { nil }
}
Which allows...
import FeatureA
...
class FeatureBImplementation: FeatureBInterface {
private var featureA = Container.featureA()
func fetchResourceB() async -> ResourceB {
let _ = await featureA?.fetchResourceA()
return ResourceB()
}
}
Then at app launch you call setup...
func setup() {
Container.featureA.register { FeatureAImplementation() }
Container.featureB.register { FeatureBImplementation() }
}
Each interface publishes an optional Factory that returns nil so it doesn't expose implementation. Anyone who uses it has to handle optional aspect, but no crash if not provided. Setup function on app registers implementations and wires the world together, much as you did before.
from factory.
Oh, and note
class FeatureBImplementation: FeatureBInterface {
@Injected(Container.featureA) private var featureA
func fetchResourceB() async -> ResourceB {
let _ = await featureA?.fetchResourceA()
return ResourceB()
}
}
If the type of the factory is optional, then the type injected is optional. No need for OptionalInjected property wrapper.
from factory.
Very interesting, thanks a lot for providing the suggestions. This means, that, in the context of the example: FeatureB
then needs to validate that necessary injected types are not nil, right ? So basically what previously was done by Resolver
internally, now needs to be done by the different Feature
implementations.
So the general idea high level idea would be:
In the Interface
we provide a "cutout" for the injected service, but set it to nil. Inside the app we fill it out with the correct implementation.
I need to think a little bit about it - I quite liked this "dynamic" approach of Resolver
- or better said, the "implicit unwrapped optional" approach. But with your suggestions, I think, I could atleast keep the base functionality. It seems I need to re-think the whole approach on my side.
Also very nice, that @OptionalInjected
is not needed any longer :)
from factory.
But I think compile time safety is definitely a very nice approach ! Great to see this improvement :) So really good work.
from factory.
I mean, there's nothing stopping you from explicitly unwrapping it on your own...
class FeatureBImplementation: FeatureBInterface {
@Injected(Container.featureA) private var featureA: FeatureAInterface!
func fetchResourceB() async -> ResourceB {
let _ = await featureA.fetchResourceA()
return ResourceB()
}
}
Other than losing the main benefit of Factory, this is. ;)
I'll still noodle on this. Let me know if you come up with something.
from factory.
Another conversation on this is occurring in issue 3.
from factory.
@hmlongco Thanks a lot for linking the other issue !
from factory.
Related Issues (20)
- Resetting instance variables on long lived object when resetting scope HOT 5
- very heavy load on the CPU HOT 9
- Cannot build XCFramework HOT 1
- Missing Registeration in Multi Module HOT 1
- Name spacing conflict HOT 4
- Are you interested for macro ? HOT 2
- Can not build app for deivce ios 15 when import Factory HOT 5
- complete Swift Concurrency Checking: "Reference to class property 'shared' is not concurrency-safe because it involves shared mutable state" HOT 1
- Using Factory in a Sendable conforming Class HOT 1
- UITests LaunchArguments Failing in Headless Mode HOT 1
- What is diffrence between this framework and singleton pattern? HOT 1
- Building xcframework on Xcode 15.0 HOT 13
- Support @Bindable with @Injected property wrappers HOT 3
- is it possible to inject swiftui view through factory? HOT 1
- Privacy manifest file HOT 3
- Issues with SPM packages and Container static shared instance HOT 2
- Question: How do I achieve scene scoped dependencies HOT 10
- Parameter factory cache does not take parameters into account HOT 2
- Xcode compile error in `FactoryKey.init(type:key:)` due to use of @inlinable HOT 3
- Release for Privacy manifest and iOS 15 HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from factory.