Sharing Environment dependencies with UIViewRepresentable views

[ferologics]

Hi, we have a situation where we need to share my Environment dependency with a UIViewRepresentable view. Unfortunately, environments are only available to the reducers, and the Store does not seem to allow sharing them in any way.

In a related discussion @mbrandonw suggested that (paraphrasing) "UIViewRepresentable views should be treated as vanilla SwiftUI views" (at least for simple use cases that permit it). Our case, however, is more complex.

We use Mapbox that we wrap in a MapView in combination with Composable Core Location("CCL") LocationManager to drive location updates. The wrapped MGLMapView has a locationManager property, which can be overridden to gain control of map location updates.

The first problem is somehow proxying the CCL's LocationManager calls and running it's effects. To replace the locationManager one has to adopt the MGLLocationManager(link) protocol.

The second problem, is actually sharing the LocationManager from the Environment with the UIViewRepresentable.

From my search I only found one related issue on the TCA Swift forums by @maximkrouk, and from my understanding of his solution:

I have to pass and map my environments twice: in reducers and in viewControllers

he is using some globally shared environment dependency that is injected twice, first in the reducer, and second time in the UIViewRepresentable view.

What are some ways that this could be achieved without violating the TCA architectural patterns? Is there a way to run ad-hoc effects without the use of a Store? We're super-duper blocked by this at the moment, and would really appreciate any solutions or workarounds that the community can share 🙏

[tgrapperon]

Maybe you can use the Environment of SwiftUI. It is accessible from context.environment in the representable, and you can set it up when you instantiate your root view, and it will automatically be transmitted to all its children. You can define a custom EnvironmentValue and pass the feature's environment along when you instantiate your root store. You can also set it up in previews with mocks.

If it's not possible, and without touching TCA inner bits, I would steal it from the reducer and store it in the state, in an optional class wrapper. It shouldn't affect automatic Equatable conformance (you can rely on the nil/non-nil state of the optional to trigger the viewStore, and implement a trivial _, _ in true when equating any wrapper's instances (this is not mandatory in this particular case though, since the value will only be updated once). On .onAppear(), you can send an action to the store. When this action is processed by the reducer, you steal the environment, wrap it and store it in the state. Your viewStore catches it and feed it as.environment(\.featureEnvironment, viewstore.wrapper?.environment) in the body. In the representable, you retrieve the optional feature's environment in the context.environment using your custom EnvironmentValue's KeyPath.

You should setup your representable so it can handle a nil environment to begin with, as you're not guaranteed to have one when the Coordinator or the UIView are instantiated. It's a little contrived, but it should work ok.
[Edit: you can also condition your representable presence to the existence of the environment in the state. In this case, you can use a non-optional value]

I would recommend the first approach with direct injection though, as you can bypass optionals and count on a non-nil environment at any time. The setup is also way simpler and doesn't have 10 reasons to go wrong. You're most likely instantiating a View right after you're instantiating your initial Store, so it should be doable to share the feature's environment at this stage and send a copy through SwiftUI's Environment.

I think it will not break any TCA principles if you're only using the environment as an environment.
I'm not a specialist with CoreLocation and I wrote this response in a general spirit, and much simpler solutions may exist.

[ferologics]

I tried using your EnvironmentValues approach but ended up with a global 🙄 it was the "cleanest" solution that works well without any magic. I don't foresee TCA focusing much effort on UIViewRepresentable so I suppose it is what it is.

[maximkrouk]

I updated the topic on the swift forum https://forums.swift.org/t/local-shared-environment/39465/3
Also, you can store view dependencies at the view level, it's not very beautiful, but you probably won't have a lot of them, so it may be a simple workaround, SwiftUI Environment or self-written environment may be a good option. But maybe you are able to create a store-managed object that will allow you to avoid using clients directly.

[maximkrouk]

And I like this approach of making ViewRepresentable objects, take a look 🙂
https://github.com/twostraws/VisualEffects/blob/main/Sources/VisualEffects/VisualEffectBlur-Mac.swift