search

nalexn / clean-architecture-swiftui

SwiftUI sample app using Clean Architecture. Examples of working with CoreData persistence, networking, dependency injection, unit testing, and more.
MIT License
5.57k stars 671 forks source link

@ObservedObject ViewModels #30

Closed RustamG closed 3 years ago

RustamG commented 4 years ago

Hi Alexey.

I see you are using @ObservedObject for ViewModels in MVVM branch. Earlier you posted an article why you quit using @ObservableObject. The main point of not using it is that you cannot simply compare ViewModels when implementing Equatable for the views because they reference the same ViewModels.

Do you have any idea on how implement Equatable for the views if the state is stored inside ViewModels?

nalexn commented 4 years ago

Hey @RustamG , yes, ObservableObject may introduce performance overhead when there are hundreds of views observing it (the case of Redux-like application with the centralized state). If there are just views inside one screen that are subscribed on a single ObservableObject (like with MVVM), the issue is not so apparent and convenience can take precedence over the performance harm (which is minimal in this case).

Majid wrote an article about how to structure the SwiftUI views so that Equatable would actually work as expected. In short: you have to split the view in two counterparts - one that references @ObservedObject or any other SwiftUI state, and another - that consumes that state as static data and renders it.

RustamG commented 4 years ago

Thanks for the tip @nalexn. Will give it a try