Environment overrides Style/onSetup(_:)

[oscbyspro]

In v4.0.0+ it works like it does in SwiftUI. I thought it was rather neat, however, that NumberTextStyle could choose the correct keyboard automatically. So I will have to think about how I can reintroduce this feature, so it works alongside the environment.

[oscbyspro]

The most straight forwards solution is to make DiffableTextStyles provide optional values for each environment value and then set values as user ?? style ?? default. I do not know if there is a better alternative, however.

[oscbyspro]

Another option is to have styles transform the environment, rather than the view. Or transform a backup environment.

[oscbyspro]

I wish Apple would’ve commented on if you’re allowed to mutate the environment in updateUIView(_:,context:), or if it’s the worst idea ever. I'mma just guess that it's a bad idea, since I dunno.

[oscbyspro]

I made my own environment in a small text-based side project, and it was implemented as a linked-list-esque-thing-y. In that case, it would’ve been fine to mutate it. SwiftUI’s environment seems link-y when using dump(_:) on it, but dunno. A backup style preferences environment is probably safer.

[oscbyspro]

Hm. I think an environment approach only works if it is guaranteed that every environment value is optional…

[oscbyspro]

Another thing I’ve been thinking about is if it makes sense for styles to be the provider of this kind of behavior. I’m not sure styles should have any platform awareness. I’m inclined to say that it doesn’t make sense, considering how much time is spent on dependency cycles. The behavior it enables is 100% desirable, however. Smart views, best views. If there’s a way to set different defaults for DiffableTextField on [some platform, some tech] where [some style] then that would be more ideal, I think.

[oscbyspro]

I don’t see a solution that is maintainable/extensible enough to warrant deviating from standard SwiftUI behavior, so I will retire this feature for the time being.