[chore]: move ViewEnvironment's EnvironmentValues key to the ViewEnvironment module

[n8chur]

Why?

Moving this environment value key to ViewEnvironment means that modules that aren't dependent on WorkflowUI (like MarketSwiftUI) are able to access ViewEnvironment keys on the SwiftUI EnvironmentValues. Market will use this key to access the MarketContext on the ViewEnvironment which is bridged by either our Market SwiftUI Hosting Controller or the standard WorkflowUI SwiftUI Screen depending on context rather than having to manually bridge the MarketContext in addition to the ViewEnvironment, and have the potential for the MarketContexts in both environments to get out of sync.

The integration in Market can be found here: https://github.com/squareup/market/pull/7763

Checklist

• Unit Tests
• UI Tests
• Snapshot Tests (iOS only)
• I have made corresponding changes to the documentation

UI-5335

[n8chur]

The file move and the added canImport here are the important bits—happy to revert the formatting changes if we'd prefer to avoid the churn!

[watt]

Would ViewEnvironmentUI be a better home? We'll need to pull that in anyway in order to bridge from VC land to SwiftUI, right?

[n8chur]

Would ViewEnvironmentUI be a better home? We'll need to pull that in anyway in order to bridge from VC land to SwiftUI, right?

I don't think so, but I might be missing something.

ViewEnvironmentUI is the framework that handles node-based propagation and integrates specifically with UIKit. I believe there is going to be a WorkflowSwiftUI module that would handle SwiftUI bridging of the ViewEnvironment—I don't think any bridging to/from SwiftUI would live in ViewEnvironmentUI, but we could talk about what the right place for that would be.
I do think it'd be nice avoid importing all of the UIKit-specific code in MarketSwiftUI (at least in its current form where it does not rely on UIKit).

[jamieQ]

hazy questions: will this impact clients that currently depend on both these targets? will the experimental library need to be bumped so it doesn't conflict with the newer ViewEnvironment implementation?

[n8chur]

will this impact clients that currently depend on both these targets?

It seems unlikely since you'd already need to import ViewEnvironment to work with the type of this environment value.

I think we should consider adding a @_exported import ViewEnvironment to WorkflowSwiftUIExperimental.

AFAIK the only client right now is MarketSwiftUI and SquareDebugMenu which I'm working with @square-tomb on and am happy to resolve an issues that come up in either repo as a result of this change! MarketSwiftUIExperimental is still experimental so changes like this should be expected (right?).

will the experimental library need to be bumped so it doesn't conflict with the newer ViewEnvironment implementation?

Are these separate version numbers/releases?

I do think we'll want to bump both of them and update consumers of these frameworks together.

[square-tomb]

Are these separate version numbers/releases?

Yep; details on that here.

[jamieQ]

thanks, that makes sense. because the definition of the extension moved but kept the same name, was just thinking whether both libraries would need a version bump to avoid ambiguous symbols (seems like they will, though perhaps it could be worked around with a module prefix).

[square-tomb]

Are these separate version numbers/releases?

Yep; details on that here.

[watt]

Would ViewEnvironmentUI be a better home? We'll need to pull that in anyway in order to bridge from VC land to SwiftUI, right?

I don't think so, but I might be missing something.

ViewEnvironmentUI is the framework that handles node-based propagation and integrates specifically with UIKit. I believe there is going to be a WorkflowSwiftUI module that would handle SwiftUI bridging of the ViewEnvironment—I don't think any bridging to/from SwiftUI would live in ViewEnvironmentUI, but we could talk about what the right place for that would be. I do think it'd be nice avoid importing all of the UIKit-specific code in MarketSwiftUI (at least in its current form where it does not rely on UIKit).

I talked to Westin out of band about this. The integration PR doesn't implement bridging so it's a little abstract to talk about. Realistically, there will be a need for bridging the ViewEnvironment from view controllers to SwiftUI without Workflow, and that has got to be in, or depend on, ViewEnvironmentUI. Will there ever be a pure SwiftUI + Workflow world that doesn't involve Screens or UIKit, and uses ViewEnvironment? I doubt it.

I like the idea of keeping the ViewEnvironment module as a simple dictionary type without adding any UI concerns, and letting ViewEnvironmentUI handle those (meaning both UIKit and SwiftUI fall under the "UI" moniker). But I don't feel strongly enough to block this for now.