How can I create an @Injected for an instance with parameters

[ipodishima]

Hi! First of all, thanks for the great work on Factory — it’s been a pleasure to use 🙌

I’m running into a design question and would love your input.

Context

I have a struct that looks like this:

struct Dependency {
    let specificProperty: String
    private var specificStorage: [/* Something specific to each usage */]
}

This Dependency is used in multiple places, for example:

class FirstClass {
    let dependency = Dependency(specificProperty: "First")
}

class SecondClass {
    let dependency = Dependency(specificProperty: "Second")
}

⚠️ These dependencies must be different instances — the specificStorage is not property-agnostic. Think of it like this:
I’m displaying a list of previews, and each preview has a StateManager. This state manager is tied to the context of the preview and must not be shared.

This is not answered by ParameterFactory since it would resolve the first call and ignore other calls to it with different parameters. Also, this is different since I need a difference instance of Dependency for each specificProperty.

My current approach

I’m using Factory with scoped containers and passing parameters:
• I create a scope for each preview.
• I store those scopes in a dictionary using a unique ID.
• I resolve dependencies on the fly from the scope.

This mostly works, but I occasionally observe that a dependency gets resolved again instead of reusing the existing one. It’s rare (~10% of the time) but problematic, since the state manager is expected to persist per preview. It might be a race condition, but it highlights that my use of Factory is not the best.

Questions

1. Is Factory designed to support this kind of use case — multiple unique instances with custom parameters per scope?
2. Would it be better to create a new Container per preview instead of relying on Scope?
3. Are there any best practices around tracking multiple scoped instances (e.g., per item in a list) with Factory?

Would love any insight or examples of how to properly model this scenario using Factory!

Thanks in advance 🙏

[ipodishima]

Updates from my findings:

I cannot use a container, because it has to be shared and I want it to be property aware.

I’m using:
• Factory(scope: .custom) with Scope.Cached
• A scoped cache manager (FactoryCachedScopeCache, it's super simple: storing scopes given properties, with lock to avoid race conditions)
• Keys that are carefully defined using a combination of IDs (e.g. projectID, templateID)
• A dictionary [Key: Scope.Cached] to ensure each (projectID, templateID) pair has a dedicated scope

Example of resolution logic:

let key = TimelineDataKey.orchestrator(projectID, templateID)
let scope = timelineDataScope(for: key)

return resolveScoped(scope) {
    TimelineDataOrchestrator(project: project, templateGenerator: generator)
}

My resolveScoped extension just wraps @factory(self, builder).scope(scope).resolve()`.

⚠️ Problem

Even though:
• The same container is used for all calls
• The same key and scope instance are confirmed via logs
• The scope is created only once
• All resolution calls happen on the main thread

Factory sometimes creates a new instance for the same scope+key pair. Logging shows that the TimelineDataOrchestrator gets allocated twice — despite the scope being identical.

I tried promoting the factory to a stored property (e.g. orchestratorFactory = Factory<T>()) and assigning .scope(scope) before calling resolve() — but the issue persists.

✅ Temporary workaround

I’m currently working around this by bypassing Factory and manually caching the instance...

This guarantees the behavior I expect, but I’d love to understand what might be going wrong with Factory’s scoped resolution, or if there’s something I’m missing in how scope caching works.

⸻

Let me know if I should try to provide a minimal reproducible example — happy to dig deeper!

Thanks 🙏

[hmlongco]

Just added....

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 2.5.0.