@ctietze One aspect I dislike about the slides in this thread is the use of the Active Record pattern for models and all services being used as singletons directly from models. This approach is impractical, difficult to mock and test, hard to use models in previews, and challenging to refactor later because all models use a concrete implementation of services A, B, C, etc.
So I always go with Model + View + Observable object or unidirectional data flow architecture.
@ctietze I partially agree with that thread. For SwiftUI apps, using MVVM can be excessive. In complex apps (100k lines of code), ViewModels can take up half of the total code, and a lot of code is often duplicated with minor adjustments specific to that view.
If you split your ViewModel code and move business logic to the model, presentation logic to the view, and introduce an Observable object with whatever name (Store, Aggregate model, etc.) you will have beautiful and clean architecture.
@ctietze I have been researching on this question for a quite some time now. I too started with MVVM with SwiftUI and went with the MVVM pattern for 3 years. I eventually realized that MVVM is not suitable for SwiftUI, since SwiftUI views are not only views but also view models so creating VM was unnecessary. I wrote a detailed article on it.
@azamsharp I really like to see reference of "Bounded Context" and similar concepts from e.g. #DDD in a SwiftUI article!
Shared state like this does make some sense. Once information needs to go up from embedded view to container view, it seems this comes naturally.
I have not experienced this approach to shared mutable state with SwiftUI, though. When stuff gets complex, I used to reach for unidirectional flow of information like #ReSwift or #TCA 🤔
@ctietze Wow that thread triggers me 🙃 I really don‘t like the way the author proposes not using MVVM like it‘s the only right thing to do. I think it absolutely depends on your use case.
@ctietze this guy posted that everywhere, numerous stack overflow questions too but I do sort of agree with him. I’ve not had much luck with adding extra view models to SwiftUI views (really complicates previews), but if you treat the view declaration like it were the view model I find everything works much nicer
@ctietze Yeah, don’t use something that was not built with SwiftUI in mind. Use #TCA instead, which is fully optimized for SwiftUI - with version 1.0 it’s getting much easier to use. With some improved documentation, it should be easy enough for everyone.
I'd consider this serious and in many cases actually good advice - albeit in bad packaging.
In a well designed app, most SwiftUI Views are actually simple, but poorly named View Models. The actual Views are the AttributeGraph that is generated with a SwiftUI View's Body.
If the Views properties are „lets“ which I'd highly recommend if possible, everything becomes fast, testable and predictable. And small.
@gernot@ctietze I agree w/ the VM thing, but I can't follow the rest. Of course, if the View's are pure functions, they are easy to test (in fact you could just write them as functions!). Well, not really, because we don't have a test hosting environment for body yet (but that may come!).
The PHP-bad thing about the approach is that interleaves state w/ presentation. Unfortunately it may become as popular as PHP! 🙈
@ctietze@gernot Note that a key motivation for doing that was a relatively complex navigation setup in an app I was working on. Not sure whether that might have been fixed w/ the new iOS 16 navigation, but I have the gut feeling that probably not 🙈
@helge@gernot I have no clear vision of how to test an object that conforms to SwiftUI.View and write assertions about its state change 🤔 But looking back 12 years or so, there was no first party testing framework at all, and the community figured out ways that worked for them. I do guess that we'll be stuck with cooking our own stuff for a while.
@helge@gernot Sorry -- I was thinking whether there was a good reason not to pass immutable state into views in SwiftUI, ever. And if that may be a habit that did stick.
@ctietze@helge Haha, it's the best way to pass things into SwftUI: SwiftUI Views themselves are immutable structs that get created and destroyed thousands of times, and inbetween they get to create an AttributeGraph in their bodies and that gets diffed with the existing attributeGraph and that animates/updates the UI… So there's nothing more natural and fast to SwiftUI than immutable structs right in the views body.
@ctietze I personally have not had great ROI on view model testing (and I never bothered with them in SwiftUI), not sure what else MVVM really brings to the table today?
@dlx@ctietze I agree, I never did those either. That might depend a lot on the number of people working on the same code though. (and I still kinda agree that SwiftUI "Views" are in many ways what used to be "View Models", though no one agrees on what those are either ...)
What I dislike about the approach is forcing everything into views, we never did that before for very good reasons. You can, but => PHP style SwiftUI ...
@helge@dlx@ctietze Nobody seems to mention it, but a good deal of logic can also be in observable objects. SwiftUI arch is Views+Models+Observable objects.
@tclementdev@dlx@ctietze That's what people usually mean when they talk about "VMs" in the SwiftUI context.
But really "ObservableObject" is just the observation mechanism (it's not even SwiftUI but Combine), e.g. models ideally are OOs in SwiftUI too (though often not the case in legacy setups). There can be other OOs, controllers, routers, view models, whatever 🙂
@helge@dlx@ctietze yes I try to use the SwiftUI lexicon otherwise it's too hard to understand what people are talking about. The way I see it, an app can have as many ObservableObject classes as needed (e.g. one for each feature of the app), they each vend models to populate views and those observable objects can contain a lot of app logic that don't otherwise really belong to views or models.
Add comment