Complex view structures are frustratingly too much work

The Java Swing and AWT MVC model made it easy to develop complex UIs with data interactions that were not described readily in a nested layer that SwiftUI demands. The implicit update model of SwiftUI greatly complicates development of applications that often requires nested components to have to know too much about other components and other structures than their own, because button events and other user interactions cannot readily alter state across layers. A button push on one component then has to be knowledgable about state in other components which have to have that state represented as @State or @Binding etc. and this causes all kinds of wiring to be spread all over the place rather than have a more centralized "state management function" that would be able to look at the world and synchronize the UIs state across changes.

The fact that the compiler get's lost in the weeds when types and signatures don't match in deeper component structures doesn't help because it makes it doubly hard to do refactoring to raise and lower state management within the structure readily, because the compiler just cannot simply tell you that a function or constructor signature is no longer correct.

This sounds like you've just not designed your code properly.

Yes, @Binding is used to represent a @State var from a different component, because they are designed that way. They are very useful, and I can see and understand why they exist.

As I suggested in your other similar post, just raise the bugs as you find them. If you raise them, they can get fixed.

Complex view structures are frustratingly too much work
 
 
Q