npvisual
commented
3 years ago Maybe we can start a discussion on this 😁 to kick things a little bit further down the road...
So from what I can tell (just getting acquainted with SwiftUI and Combine), it appears that SwiftUI forces the Binding layer into the View declarations with @EnvironmentObject and @ObservedObject. Effectively making the Binding layer sort of obsolete in that context.
I.e. any sort of binding between information provided by a service and a view, in the Binder Architecture, is pushed inside the View's struct declaration in most of the SwiftUI samples I have seen. That couples the model and the view definition very tightly and doesn't give much space to create the view / binding / service separation.
Using an intermediary object that relies on very simple types (String, Int, Bool, etc.) to be included in the View definition and then using that object in the Binding to bridge between the service data and the view data is one way to close the gap between SwiftUI and the Binder Architecture to leave as much of the Service logic hidden from the View.
However this only works well for changes in the "state" model. Actions on the other hand seem to be more difficult to abstract away from the View's struct definition (button clicks that drive an action, for example).
Would love to hear suggestions on how to make this "integration" possible...
Since ReactiveKit is in the process of API alignment with Apple's Combine framework, and more and more people are using SwiftUI, would it make sense to revisit the Binder Architecture and update it to reflect the use of both frameworks (Combine + SwiftUI)?
I'd find it particularly interesting to understand the impact on existing code as I am slowly learning/moving to Combine and SwiftUI (the latter somewhat forcing the former into light).
The AbsurdGitter sample would be a nice side-by-side comparison, especially if it showed how SwiftUI somewhat aligns with the concepts introduced by LayoutLess in this example.
Thanks!