Inject Environment value as Dependency

[ltns35]

Hi everyone,

I'm working on a use case where I need to pass an environment value as a dependency to be used within a feature. Right now, I'm handling this manually by assigning the environment value to a state variable inside the .onAppear modifier. However, this approach adds quite a bit of boilerplate code.

To reduce repetition, I'm considering creating a custom ViewModifier to encapsulate this logic and make it reusable.

Has anyone tackled a similar scenario? I'd appreciate any advice or best practices for implementing this pattern effectively.

Thanks in advance!

[mbrandonw]

Hi @ltns35, it is not possible to support this kind of thing. SwiftUI does not open up enough of their internal APIs to allow one to use environment values outside of views. There may be hacks you can employ, but it's hard to give concrete advice without more information. Can you share some code that demonstrates what you are trying to achieve?

[ltns35]

This is the code I currently have and its working, but I need to call the function in all the screens.

private struct NavigatorAdaptor: ViewModifier {
    @Environment(\.navigator)
    private var navigator

    @Binding
    private var nav: Navigator?

    public init(_ nav: Binding<Navigator?>) {
        _nav = nav
    }

    func body(content: Content) -> some View {
        content
            .onAppear {
                nav = navigator
            }
    }
}

public extension View {
    func exposeNavigator(_ navigator: Binding<Navigator?>) -> some View {
        modifier(NavigatorAdaptor(navigator))
    }
}

What I want to do is call the exposeNavigator on the root of the navigation and from the feature access to the navigator as a @Dependency.

The main problem I'm facing with TCA is the navigation between isolated modules with a navigation framework that decouples the navigation.

[mbrandonw]

The main problem I'm facing with TCA is the navigation between isolated modules with a navigation framework that decouples the navigation.

Hi @ltns35, there really is nothing special about TCA in this regard. The same problems arise the moment one tries to put some feature logic in an @Observable model. You are invariably led to a situation where things exist in the environment that you would like to have access to in the @Observable model (or TCA feature).

And the solution to this problem is the same whether you are using an @Observable model or a TCA feature. There are two things you can do:

1. You can can use an onAppear of the view to hand the environment value over to the model/reducer so that it can be used where your feature's logic is. However, typically these kinds of "navigators" are not equatable, and so that will complicate the Equatable conformance of your feature's state. This means you won't be able to use TestStore for testing, but then again @Observable models aren't very testable also.

2. You can use state in the model/reducer to communicate to the view that it wants something done. For example, your State can hold a isNextScreenPresented: Bool value, and then the view listens to changes of that value to then communicate with the "navigator":

   .onChange(of: store.isNextScreenPresented) {
     if store.isNextScreenPresented {
       navigator.push(.nextScreen)
     }
   }

That is the basic idea. Again, this exact same story plays out in vanilla SwiftUI and is not really a problem of TCA.