3 ms·

There are a lot of foot guns, like ObservableObject and @Published causing views that reference the object (even if they don't use it in any way) to be re-rende

There are a lot of foot guns, like ObservableObject and @Published causing views that reference the object (even if they don't use it in any way) to be re-rendered that cause issues. And even Apple can't figure it out, which can be seen from the Ventura System Settings performance. SwiftUI is nice for small apps and demos. But as soon as you add persistence, or try and do anything advanced the complexity balloons and you need to understand it completely. I think SwiftUI is just a bad abstraction with a lot of accidental complexity. It makes drawing much easier/faster for developers but all the state management stuff has become very difficult.

fingerlocks 4y ago
Apple can figure it out- they implemented @Published such that it contains a reference to it's enclosing ObservableObject which invokes objectWillChange() very liberally. The fact that they wrote their settings UI poorly is a statement about the developer's assigned to build those components and/or the lack of QA involved. I do agree that ObservableObject/@Published should have been designed to prevent unnecessary re-renders. It's actually quite easy, and I expect Apple will include this in the future: Add an extension to @Published when the value type is Equatable and only send objectWillChange() when newValue != oldValue. I do something like this in my apps to eliminate superfluous re-renders, but the implementation is non-trivial due to an undocumented feature in Swift [0]. [0] https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md#referencing-the-enclosing-self-in-a-wrapper-type https://github.com/apple/swift-evolution/blob/main/proposals...