What's TCA's stance on live-only dependencies?

[davdroman]

I'm working on a codebase where many instances of JSONDecoder are being injected everywhere with the exact same configuration into TCA clients' convenience methods.

struct FooClient {
    let doSomethingWithBar: @Sendable async (Bar) -> Void
}

extension FooClient {
    func decodeBarAndDoSomethingWithIt(_ data: Data, decoder: JSONDecoder = .iso8601) async throws {
        let bar = try decoder.decode(data, as: Bar.self)
        await doSomethingWithBar(bar)
    }
}

The implementation is not really relevant, but what's relevant is whether injecting decoder everywhere is a good idea or whether we'd benefit from @Dependency like this:

extension JSONDecoder: DependencyKey {
    public static let liveValue: JSONDecoder = {
        let decoder = JSONDecoder()
        decoder.dateDecodingStrategy = .iso8601
        return decoder
    }()
}

// later...

extension FooClient {
    func decodeBarAndDoSomethingWithIt(_ data: Data) async throws {
        @Dependency(\.jsonDecoder) var decoder
        let bar = try decoder.decode(data, as: Bar.self)
        await doSomethingWithBar(bar)
    }
}

Does this make sense? FooClient will only be called from reducers so the dependency will always be found, but what boggles me a bit is that the dependency should always be live, including in tests and previews. Is that considered good etiquette, or am I misusing @Dependency?

I can think of other use cases for live-only dependencies such as date or number formatters, and it actually kinda makes sense for those to exist like this because they would need @Dependency(\.locale) and other subdependencies in order to be configured as expected.

I appreciate any thoughts on this.

Note: I freehanded this code so there might be syntactical inconsistencies.

[mbrandonw]

It is totally fine to use @Dependency in the way you have done here, and it's totally fine to have the test/preview/live value all be the same thing. You can even use @Dependency outside the context of a reducer, which is why we may open source it as a separate library someday soon.

But, I do have a question. Is there ever a time that a non-JSONDecoder.iso8601 is used? If everything should be using it, then maybe it's ok just to have a global value that all code can use?

However, if non-.iso8601 values can be used, then I think what you have done here is fine, and again it is OK for the test/preview/live value to all be the same thing.

[davdroman]

If everything should be using it, then maybe it's ok just to have a global value that all code can use?

It's a new codebase so I haven't yet seen all usage, but from what I was able to quickly find via search and replace .iso8601 is sprinkled everywhere.

I agree on potentially going with a global, although it makes me a bit nervous visibility-wise. There's something really comforting about scoped @Dependencys.

Thanks for your prompt answer!