Closed ericlewis closed 2 years ago
Result of the investigation was to use enums & associated values:
struct SheetContentView: View {
var body: some View {
Text("Hello World")
.sheetPreference(.grabberVisible(true))
}
}
This satisfies the following:
The reason enums are used instead of key paths is that there is no equivalent struct to EnvironmentValues
for preferences. It wouldn't really make sense to have one either, since preferences aren't consolidated that way. Enum provides most of the same functionality and shape as the KeyPath api.
It's hard to remember all of the configuration methods. Sometimes they aren't so obvious in isolation (what is preferring a grabber visibility deep in this component hierarchy?). It's hard to discover the apis for quick configuration. I am leaning towards something similar to
environment(_, _)
. Like this:The
sheet
method name makes sense, but other ideas should be considered as well:.presentation(...)
.pageSheet(...)
.presentationPreference(...)
.sheetPreference(...)
There isn't really much prior art around organized interaction with Preferences aside from creating bespoke methods like environment interactions.
I will note that using preferences the KV way doesn't make it completely obvious that we are moving upwards like a typical preference setting might. Likely important to keep
preference
somewhere in the signature.Another useful tool may be a property wrapper to be able to read from preferences:
This opens the potential for simplifying the entire configuration pipeline.
Food for though 🍎