Post

Replies

Boosts

Views

Activity

Comment on Stop using MVVM for SwiftUI
Thanks very much for this, this helps a lot. In my example, I was considering that “Favourite” would be an attribute on the file itself, but not necessarily read from the file system (it could be coming from UserDefaults or somewhere else). Question 1: In your example 1, favourites is not a published var. Is it considered to be a computed property in this case? It's not published because any changes to the favourites would also change “all” which would then cause SwiftUI to recompose the scene?
Sep ’22
Comment on Stop using MVVM for SwiftUI
Question 2: In the “active record” pattern, could a struct like “FileItem” ever have a reference to a Store (for example if we had an setAsFavourite method)? Or is this an anti-pattern? If it needs a reference to the store, we’d just put the method on the Store itself? Is active record meant to be used more with libraries and not apps? I'm just wondering how it would work putting methods on the struct when the struct might need references to other subsystems in the app.
Sep ’22
Comment on Stop using MVVM for SwiftUI
In this example, if I understand correctly, it would be better to not use Active Record or if we do, to make sure mutations happen through the StateObject and not by calling functions directly on the active record? That lines up with what I observed so seems to make sense!
Sep ’22
Comment on Stop using MVVM for SwiftUI
When you say call call objectWillChange.send(), is this replacing @Published? I.e: We call call objectWillChange.send(), then SwiftUI will redraw the view, and automatically get the new contents when it re-reads Folder.folders? In Example 2, we're depending on the FileWatcher to invalidate the view right? I.e.l FileWatcher should be sending an objectWillChange.send(), so we get all the correct values inside the view body when all of the properties are re-queried?
Sep ’22