Injecting nested dependencies in environment

[MartinP7r]

Hi @groue 👋🏼 ,

thanks for providing such a well-documented package, as always!
I'm in the process of trying out @EnvironmentStateObject on my pet project and ran into some architectural questions.
I might be getting something awfully wrong architecture-wise, but here goes:

Consider several layers depending on each other.
Repositories (PlayerRepository, ...) depend on the persistence layer (e.g. AppDatabase in your example app), a MatchService depending on the repository.

Now we have something like

let repo = PlayerRepository(db: AppDatabase.shared)
let service = MatchService(repo: repo)

The service is used in a SwiftUI view, let's call it MatchView.

With a view model initialization:

@EnvironmentStateObject private var vm: ViewModel

init() {
    self._vm = EnvironmentStateObject { env in
        ViewModel(matchService: env.matchService)
    }
}

Env setup

@main
struct JDictApp: App {
    @Environment(\.database) private var db
    @Environment(\.playerRepo) private var playerRepo
    // ...

    var body: some Scene {
        WindowGroup {
            MatchView()
                .environment(\.matchService, MatchService(repo: playerRepo))
    // ...
    }
}

For SwiftUI Previews:

MatchView()
    .environment(\.database, .empty())
    .environment(\.matchService, MatchService(repo: /* ??? */))

Here the MatchService won't be able to get the in-memory database from the environment.
Short of having something like MatchService.preview or a service (or view model) factory in the environment, I don't see a good pattern that would solve this without too much boiler plate.

Do you have any thoughts or ideas on this topic?

[groue]

Hello @MartinP7r,

I don't see any problem with modifying multiple environment keys in previews:

private struct Service1Key: EnvironmentKey {
    static let defaultValue = false
}

private struct Service2Key: EnvironmentKey {
    static let defaultValue = false
}

extension EnvironmentValues {
    var service1: Bool {
        get { self[Service1Key.self] }
        set { self[Service1Key.self] = newValue }
    }
    
    var service2: Bool {
        get { self[Service2Key.self] }
        set { self[Service2Key.self] = newValue }
    }
}

class MyViewModel: ObservableObject {
    let service1: Bool
    let service2: Bool
    
    init(service1: Bool, service2: Bool) {
        self.service1 = service1
        self.service2 = service2
    }
}

struct MyView: View {
    @EnvironmentStateObject private var viewModel: MyViewModel
    
    init() {
        _viewModel = EnvironmentStateObject { env in
            MyViewModel(service1: env.service1, service2: env.service2)
        }
    }
    
    var body: some View {
        HStack {
            Text(viewModel.service1 ? "1: Custom" : "1: Default")
            Spacer()
            Text(viewModel.service2 ? "2: Custom" : "2: Default")
        }
    }
}

struct MyView_Previews: PreviewProvider {
    static var previews: some View {
        VStack {
            MyView()
            MyView()
                .environment(\.service1, true)
            MyView()
                .environment(\.service2, true)
            MyView()
                .environment(\.service1, true)
                .environment(\.service2, true)
        }.padding()
    }
}

[MartinP7r]

Thank you for the answer. I see.
My problem is more about, cases where there are multiple layers of dependencies in the environment.
This is not a problem with EnvironmentStateObject, but rather with using the SwiftUI environment for DI in general, I think.

But I guess the answer to that would inherently be the same. Just initializing all of the nested values in the Preview's environment as well.

Let me change your example to illustrate my point:

class Service1 {
    let isOn: Bool

    init(isOn: Bool = false) {
        self.isOn = isOn
    }
}

class Service2 {
    private let service1: Service1

    init(service1: Service1 = Service1()) {
        self.service1 = service1
    }

    static let shared = Service2()

    var isOn: Bool { service1.isOn }
}

private struct Service1Key: EnvironmentKey {
    static let defaultValue = Service1()
}

private struct Service2Key: EnvironmentKey {
    static let defaultValue = Service2.shared
}

extension EnvironmentValues {
    var service1: Service1 {
        get { self[Service1Key.self] }
        set { self[Service1Key.self] = newValue }
    }

    var service2: Service2 {
        get { self[Service2Key.self] }
        set { self[Service2Key.self] = newValue }
    }
}

class MyViewModel: ObservableObject {
    let service1: Service1
    let service2: Service2

    init(service1: Service1, service2: Service2) {
        self.service1 = service1
        self.service2 = service2
    }
}

struct MyView: View {
    @EnvironmentStateObject private var viewModel: MyViewModel

    init() {
        _viewModel = EnvironmentStateObject { env in
            MyViewModel(service1: env.service1, service2: env.service2)
        }
    }

    var body: some View {
        HStack {
            Text(viewModel.service1.isOn ? "1: Custom" : "1: Default")
            Spacer()
            Text(viewModel.service2.isOn ? "2: Custom" : "2: Default")
        }
    }
}

struct MyView_Previews: PreviewProvider {

    static var previews: some View {
        let service1 = Service1(isOn: true)
        let service2 = Service2(service1: service1)
        return VStack {
            MyView()
            MyView()
                .environment(\.service1, service1)
            MyView()
                .environment(\.service2, service2)
            MyView()
                .environment(\.service1, service1)
                .environment(\.service2, service2)
        }.padding()
    }
}

I feel like this wouldn't scale very well with increasing numbers of services.
But then again, there probably shouldn't be too many dependencies in a single view, to begin with.

[groue]

Sorry for the late response. I'm not sure about the problem you face, or what you expect, to be honest.

My confusion is made worse by the fact that there are two Service1 instances in your environment. One is embedded in Service2, an the other is provided as an independent environment key. With such a design, both instances may differ, obviously.

I can't decide if it is a problem, or not, in your application, that both instances can differ. If it is a problem, then you have to handle service consistency. Some object could take care of that. For example:

class Service1 {
    let isOn: Bool

    init(isOn: Bool = false) {
        self.isOn = isOn
    }
}

class Service2 {
    private let service1: Service1

    init(service1: Service1 = Service1()) {
        self.service1 = service1
    }

    var isOn: Bool { service1.isOn }
}

/// The object that guarantees service consistency
struct Services {
    let service1: Service1
    let service2: Service2
    
    init(service1: Service1) {
        self.service1 = service1
        self.service2 = Service2(service1: service1)
    }
}

private struct ServicesKey: EnvironmentKey {
    static let defaultValue = Services(service1: Service1())
}

extension EnvironmentValues {
    // Guaranteed consistent services
    var services: Services {
        get { self[ServicesKey.self] }
        set { self[ServicesKey.self] = newValue }
    }
    
    // Convenience accessors
    var service1: Service1 { services.service1 }
    var service2: Service2 { services.service2 }
}

class MyViewModel: ObservableObject {
    let service1: Service1
    let service2: Service2

    init(service1: Service1, service2: Service2) {
        self.service1 = service1
        self.service2 = service2
    }
}

struct MyView: View {
    @EnvironmentStateObject private var viewModel: MyViewModel

    init() {
        _viewModel = EnvironmentStateObject { env in
            MyViewModel(service1: env.service1, service2: env.service2)
        }
    }

    var body: some View {
        HStack {
            Text(viewModel.service1.isOn ? "1: Custom" : "1: Default")
            Spacer()
            Text(viewModel.service2.isOn ? "2: Custom" : "2: Default")
        }
    }
}

struct MyView_Previews: PreviewProvider {
    static var previews: some View {
        let customService1 = Service1(isOn: true)
        return VStack {
            MyView()
            MyView()
                .environment(\.services, Services(service1: customService1))
        }.padding()
    }
}

[MartinP7r]

No worries! I'm grateful for any response and this wasn't late in any way. Thanks for taking the time 🙏

This is similar more or less the concept I had in mind.
My problem was that I couldn't quite grasp how to make this fully testable.
In your example as well, Service2 wouldn't be replaceable, by a mock for example.
But I think that could be solved by using a factory for Service2, like:

 init(service1: Service1 = Service1(), service2Factory: Service2FactoryProtocol) {
        self.service1 = service1
        self.service2 = service2factory.createService(service1: service1)
    }

Also, I love the idea with the convenience accessors. 👍🏼

[groue]

Ha, yes, I see. Maybe this kind of complex scenario explains why there are so many Dependency Injection libraries out there.

I remember having been impressed by the simplicity of the How to Control the World article. In the context of SwiftUI, the "world" described by the article is simply the SwiftUI environment. In my applications inspired from this article, avoiding inconsistent services indeed requires discipline (because everything can be freely modified 😨). But this discipline isn't difficult in practice 🤓:

• At initialization, the app creates the useful service instances, and connects them together, before registering eventual shared instances and feeding the SwiftUI environment once and for good. Services are practically never modified during app runtime (we can, but we don't).
• Tests and previews are easy to setup with real or mock services, especially when the default world/environment raises errors (fatal or not) on accesses to services that are not supposed to be used from this test of preview.
• The app can even run live showcases by overriding the SwiftUI environment with dedicated services in showcased views. The ability to run showcases as a light replacement for UI tests is invaluable - especially when testers can run them and check the behavior of the app in various conditions. It's trivial to see how the app handles flaky network connections, various user/network inputs, etc. When the app allows showcases to run on top of the "real" application, discipline is indeed required because app services are still living underneath. But one can still make showcase-dedicated builds, in which case conflict with app services can't happen.

Some developers or teams would not accept such a freedom, though.