Add full support for `@Environment` variables
One of the ways to programmatically dismiss a view is by using: @Environment(\.presentationMode) var presentationMode then calling presentationMode.wrappedValue.dismiss().
So if you've launched that view with a Binding of some kind, say you used NavigationLink with $isActive. When dismissed is called that binding does get set to false in production code. However I'm not sure ViewInspector triggers all the appropriate lifecycle things to have that work.
Is there an obvious way to test this I simply don't understand? Is this untestable? Could we get it as a feature enhancement?
Hey, that is correct, the @Environment(\.presentationMode), along with the new @Environment(\.isPresented) and @Environment(\.dismiss) are not updated nor are observed by ViewInspector because it doesn't have access to the EnvironmentValues store.
If you print a view with @Environment(\.presentationMode), you'll see the variable:
_presentationMode: Environment<Binding<PresentationMode>>
content: Content
keyPath: WritableKeyPath<EnvironmentValues, Binding<PresentationMode>>
_kvcKeyPathStringPtr: Optional<UnsafePointer<Int8>> = nil
Unlike @EnvironmentObject property wrapper, which inner var references the object, this one only carries the keyPath, and the value is stored elsewhere, in internal SwiftUI storage.
Access to that storage is private, we cannot patch it either.
The other way could be to swizzle the wrappedValue getter for the Environment property wrapper to return a custom Binding<PresentationMode> that we manage - but Swift does not offer swizzling for value types.
I'll keep this ticket open in case we find a way to access the EnvironmentValues.
I know it's random to come back to this so long later, but there might be an interesting way to access environment values: @Environment(\.self) var env
from: https://blog.eidinger.info/dump-swiftui-environment-efficiently
Figured I'd note that if and when anybody got around to playing with this.