The tale of .environment(\.backgroundProminence, _) is just the kind of thing that makes SwiftUI so difficult when you're off the beaten path. Its API is super composable, but discoverability suffers compared to traditional OO view systems: Although Swift's language design is oriented toward IDE completion after a ., when there are hundreds of options in that popup, you have to hit the docs after all. View modifiers often just set environment values, and environment values' effects on particular views aren't documented and the source is closed, so in unfamiliar territory you can expect trial and error.
The reality is just different. The UI is a "thing" that communicates with the model. This communication, this dataflow, is an important aspect of the system, you can't hide it away behind magic @ incantations. Well you can, but you can't expect it to turn out well.
Whereas these system pretend that the UI is or should be completely ephemeral, for the user the UI is / should be the most solid piece of the system.
The content of the UI is a function of the model, though it isn't pure.
I found that article a bit hard to understand, I don't disagree with that UI can get a lot messier than a pure function allows, but still having a way to ergonomically manage side-effects seems to be desirable no?
I like declarative stuff, but I don't think they are the endgame of UI stuff.
SwiftUI is so annoying - it’s basically “let’s do a completely new UI API, it will be easy because we can make it looks different so people will know to not expect it to behave like Mac apps have done for the last 20 odd years”
kevinc | 18 hours ago
The tale of
.environment(\.backgroundProminence, _)is just the kind of thing that makes SwiftUI so difficult when you're off the beaten path. Its API is super composable, but discoverability suffers compared to traditional OO view systems: Although Swift's language design is oriented toward IDE completion after a., when there are hundreds of options in that popup, you have to hit the docs after all. View modifiers often just set environment values, and environment values' effects on particular views aren't documented and the source is closed, so in unfamiliar territory you can expect trial and error.mpweiher | 18 hours ago
There is way too much magic involved in trying to make the false claim "UI is a pure function of the model" appear true.
UIs Are Not Pure Functions of the Model - React.js and Cocoa Side by Side
The reality is just different. The UI is a "thing" that communicates with the model. This communication, this dataflow, is an important aspect of the system, you can't hide it away behind magic @ incantations. Well you can, but you can't expect it to turn out well.
Whereas these system pretend that the UI is or should be completely ephemeral, for the user the UI is / should be the most solid piece of the system.
The content of the UI is a function of the model, though it isn't pure.
zetashift | 18 hours ago
I found that article a bit hard to understand, I don't disagree with that UI can get a lot messier than a pure function allows, but still having a way to ergonomically manage side-effects seems to be desirable no?
I like declarative stuff, but I don't think they are the endgame of UI stuff.
olliej | 10 hours ago
SwiftUI is so annoying - it’s basically “let’s do a completely new UI API, it will be easy because we can make it looks different so people will know to not expect it to behave like Mac apps have done for the last 20 odd years”