Introduce AdaptedEnvironmentScreen, for modifying the ViewEnvironment when creating screens

[kyleve]

This mirrors the API allowed on Elements in blueprint, to ease ViewEnvironment modification. For example, you might do something like this:

func render(...) -> Rendering {
    MarketSelectSheetScreen( ... construct your select actions ...)
        .adaptedEnvironment(keyPath: \.isContentAreaEnabled, value: state.isSaving == false)
}

Checklist

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

[square-tomb]

Doesn't really matter because this is a value type, but why can't these be let? It doesn't look like we're using their varness in the implementation, tests, or sample usage.

[kyleve]

I tend to just keep things as var unless let is absolutely required (eg, consistency between variables), mostly as a purely stylistic thing.

[jamieQ]

IIUC, the type of this variable is something like:

AdaptedEnvironmentScreen<AdaptedEnvironmentScreen<...<TestScreen>...>>

is allowing nesting like that in the type desirable? in practice would this sort of thing be expected to occur?

there are a few alternatives i can think of for accumulating the environment mutations, but just wondering if it seems worthwhile to explore them.

[kyleve]

It will be, yeah. I think that's generally fine; since deeply nesting like this in practice won't really occur. This test is a bit of a degenerate test, designed to simulate many adaptedEnvironments that could be throughout your Screen tree.

there are a few alternatives i can think of for accumulating the environment mutations

We do this in Blueprint, but its a lot easier because the AdaptedEnvironment element there isn't generic around the element type; the generics make this much more difficult.

[jamieQ]

at first glance, this seems a bit confusing, and almost feels backwards. i can see why it is true and expected (the adapters are applied from 'outside in'), but it makes the example code above seem more confusing. since the outer wrappers that attempt to adapt earlier keys effectively do nothing, does it make sense to allow them to be written? should there be some form of warning produced if clients attempt to do this? as implemented here, this might not be possible to detect, but just something maybe worth considering.

[kyleve]

I mentioned this above; but this is basically a somewhat artificial test / a test designed to simulate where these adaptations happen throughout the screen tree; to make sure the "last write wins" is true.

should there be some form of warning produced if clients attempt to do this

I don't think this is really possible; without also including the ViewEnvironmentKey in the generic of the screen; which then also means we'd need to get rid of the keypath and closure-based modifiers.

[kyleve]

Looking at #106 from @bencochran, I think I should likely move this conformance to an extension.

[kyleve]

#198