Parent dependency is resolved from cache after child has changed, instead of being recalculated

[kirillsh]

Description

In our project we're using dependencies that rely on other lower level dependencies. We're usually doing that by declaring @Dependency(\.child) property wrapper inside parent's implementation of liveValue.
But because parent's value is cached upon its first resolution -> no matter how we override the child's value, the parent will not be recalculated capturing its child's initial value.
This might produce unexpected side effects like in the example below.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

Parent.liveValue is recalculated after Child is overwritten.

Actual behavior

Parent.liveValue is resolved from cache capturing the initial Child value.

Steps to reproduce

// -------- Declaring dependencies

struct Parent: DependencyKey {
    let child: Child
    
    static var liveValue: Parent {
        @Dependency(Child.self)
        var child
        
        return Self(child: child)
    }
}

struct Child: DependencyKey {
    let id: String
    
    static let liveValue = Child(id: "Child")
}

// --------- Consuming dependencies

withDependencies {
    $0[Child.self] = Child(id: "Overriden Child")
} operation: {
    @Dependency(Parent.self)
    var parent
    
    print(parent.child.id) // "Overriden Child"
}

@Dependency(Parent.self)
var parent

print(parent.child.id) // Expected: "Child", Actual: "Overriden Child"

Dependencies version information

1.3.0

Destination operating system

iOS 17

Xcode version information

15.4

[mbrandonw]

Hi @kirillsh, the behavior you have demonstrated above is to be expected. By doing this:

static var liveValue: Parent {
  @Dependency(Child.self) var child      
  return Self(child: child)
}

…you have decided to resolve the Child dependency at this moment and pass a concrete version of the child to Parent. There will not be another resolution of this dependency at a later time, and so nothing can change its value. The Child object is held inside the Parent outside of the dependency system.

I'm not entirely sure what you are trying to accomplish in your real code. Perhaps you can share something more real world. But since this isn't an issue with the library I am going to convert it to a discussion, and please feel free to continue the conversation over there.

[kirillsh]

Perhaps you can share something more real world

Maybe I went too far in abstracting out the real world use case.
Here is more specific example:

// ----- Declare types and dependencies

struct ApiClient {
    var fetch: () async -> Response
}
 
struct Response {
    var payload: String
}

struct ResponseDecoder {
    var decode: (Data) -> Response
}

struct Network {
    var get: (_ path: String) async -> Data
}

extension ApiClient: DependencyKey {
    static var liveValue: ApiClient {
        @Dependency(ResponseDecoder.self)
        var decoder
        
        @Dependency(Network.self)
        var network
        
        return live(network: network, decoder: decoder)
    }
    
    static func live(network: Network, decoder: ResponseDecoder) -> Self {
        Self {
            let data = await network.get("/path/to/endpoint")
            
            return decoder.decode(data)
        }
    }
}

extension ResponseDecoder: DependencyKey {
    static var liveValue: ResponseDecoder {
        // todo: default implementation
        Self { _ in
            Response(payload: "default")
        }
    }
    
    static var specialCase: ResponseDecoder {
        // todo: special case implementation
        Self { _ in
            Response(payload: "special case")
        }
    }
}

extension Network: DependencyKey {
    static var liveValue: Network {
        // todo: network implementation
        Self { _ in
            Data()
        }
    }
}

// ----- Consume dependencies in a feature

func fetchResponse(isSpecialCase: Bool) async -> Response {
    if isSpecialCase {
        return await withDependencies {
            $0[ResponseDecoder.self] = .specialCase
        } operation: {
            @Dependency(ApiClient.self)
            var apiClient
            
            return await apiClient.fetch()
        }
    } else {
        @Dependency(ApiClient.self)
        var apiClient
        
        return await apiClient.fetch()
    }
}

// Then we'll get different results depending on which call comes first:

// 1. special case first -> unexpected value for defaultResponse
let specialCaseResponse = await fetchResponse(isSpecialCase: true) // special case
let defaultResponse = await fetchResponse(isSpecialCase: false)// actual: special case, expected: default

// 2. default case first -> unexpected value for specialCaseResponse
let defaultResponse = await fetchResponse(isSpecialCase: false) // default
let specialCaseResponse = await fetchResponse(isSpecialCase: true) // actual: default, expected: special case

[kirillsh]

I've found a workaround but I'd like to still raise few questions:

• is it intuitive for the developer implementing liveValue for their dependency that despite being a calculated var it won't be recalculated because of the cache? At least it wasn't intuitive for me.
• wouldn't be beneficial for the swift-dependencies library to resolve such cases in an expected way (invalidate related dependencies in the cache) to allow for their recalculation?
• If cache of dependencies alters the behaviour (depending on which call comes first - you'll get different results) and disabling that cache fixes the issue - isn't it a sign that smth. is wrong with the cache implementation?

IMHO from the first view it shouldn't be that difficult to support relations of dependencies with each other, e.g. by making cache implementation aware of "list of dependencies that relate to the current dependency". Seems like library could detect when @Dependency is being resolved inside liveValue implementation of another dependency and store them in the list.

[stephencelis]

is it intuitive for the developer implementing liveValue for their dependency that despite being a calculated var it won't be recalculated because of the cache? At least it wasn't intuitive for me.

The cache was added at a later date because people didn't find the uncached behavior intuitive. Many times users will introduce computed static vars that require some configuration code, and this would subtly break their applications. Because dependencies are basically treated as singletons in most code bases, and only commonly overridden in tests, a lack of cache made most of these dependencies stateless by default. The one gotcha is the one you encountered, where an inline dependency that is resolved outside the default scope will be cached into the default scope. We're not sure if there are ways to address this, but are open to suggestions.

wouldn't be beneficial for the swift-dependencies library to resolve such cases in an expected way (invalidate related dependencies in the cache) to allow for their recalculation?

The main issue here is that stateful dependencies may lose their state (e.g. a logged-in API client may lose its token), but if you have a suggested way to achieving this we're open to discussing a PR!

If cache of dependencies alters the behaviour (depending on which call comes first - you'll get different results) and disabling that cache fixes the issue - isn't it a sign that smth. is wrong with the cache implementation?

We're open to any improvements here if you have any suggestions. The cache is quite simple, but the complication is how task locals propagate.