Open elprl opened 1 year ago
Update: I managed to get access to the Core Data objects in the snapshot via:
itemsSnapshot.compactMap { $0.object }
Not mentioned in the docs, so not sure if this is a good tactic.
Hi, have you checked the CoreStoreDemo project? There are examples on how to use ListPublisher
s in tandem with ListReader
s and ObjectReader
s depending on whether you need ObjectPublisher
s or ObjectSnapshot
s in your SwiftUI View
s
Yes, I did thank you. I also looked at the unit tests. Like I said in my intro, I'd rather not have the View have a dependency on the CoreStore library, but the view model is fine.
In my experience, in more complex enterprise use cases, one rarely goes from a Core Data object straight to View. A ViewModel or Interactor grooms, processes, filters, combines, splices the core data before forming a viewModel object.
Additionally, the .object
variable isn't mentioned in the readme. I think your Readme section on Combine needs a better example that accounts for this grooming & processing.
listPublisher.reactive
.snapshot(emitInitialValue: true)
.flatMap { // or compactMap { // or map {
... // more grooming
.sink...
I went straight to this section and thus was confused as to what the datasource
object was. It doesn't help situations that don't need to be coupled with the View.
The API provides the necessary endpoints for your app. If you prefer not to depend on CoreStore, then you would have to write that layer yourself.
.object
is not documented because it's not the recommended way to access values from an ObjectPublisher
, especially in SwiftUI where the View
works with value types. The framework ensures your View
s properly receives notifications because .object
instance on its own will not tell your View
to refresh if that object gets updated. I'm not sure how you'd even use .object
without depending on CoreStore, because that object is of CoreStoreObject
type anyway, in which case it is still better to use either ObjectPublisher
directly, or ObjectSnapshot
which is a value type.
I'm not sure how you'd even use
.object
without depending on CoreStore, because that object is ofCoreStoreObject
type anyway
Ah, I guess you are using NSManagedObject
s directly instead of CoreStoreObject
s. Nevertheless, you will still be better off using the right wrappers (ObjectPublisher
or ObjectSnapshot
) to properly sync your views.
Appreciate the comments John, I do like what CoreStore has achieved. I think the library is not addressing a common architectural pattern, where a ViewModel
class is doing the syncing as you mentioned. If I wasn't going to use CoreStore, I would be doing something like this:
https://www.donnywals.com/observing-changes-to-managed-objects-across-contexts-with-combine/
To give a crude example, let's say you have a Whatsapp style app. Core Data would store the encrypted Message
, the ViewModel
class would create a listener for new & updated Message
objects, and when they arrive would process each Message
, decrypt them, convert dates into strings, add colours, etc, and finally create a MessageViewModel
object for the View
to consume. In this scenario, the View
is decoupled from both Core Data and Core Store. We all know mocking Core Data for SwiftUI previews and unit tests is overly complex and hard work.
So how does one achieve this? Something like:
class ViewModel: ObservableObject {
@Published var messageViewModels: [MessageViewModel] = []
init() {
let listPublisher = dataStack.publishList(
From<Message>()
.orderBy(.ascending(\.timestamp))
)
listPublisher.reactive
.snapshot(emitInitialValue: true)
.receive(on: RunLoop.main)
.flatMap { snapshot in
// convert snapshot into MessageViewModel array
}
.sink(receiveCompletion: { completion in
...
}, receiveValue: { [weak self] messageViewModels in
self?.messageViewModels = messageViewModels
})
.store(in: &cancellables)
}
}
I understand that there are architectures where you have to provide the per-object ViewModels directly, and in fact we do use similar cases in our projects. The problem is that SwiftUI kind of forces us to wrap our ViewModels in some sort of @State
or @ObservableObject
or something similar for View
s to get updated properly. A large part of the observation logic similar to the one in Donny Wal's article you have linked is already provided in CoreStore's @ListState
and @ObjectState
and are ready to be used in SwiftUI projects.
(see Modern.ColorsDemo.SwiftUI.ListView.swift and Modern.ColorsDemo.SwiftUI.DetailView.swift in the Demo app)
Now of course you are free to limit the dependency to CoreStore and implement this yourself. In that case, I would still recommend you check how @ListState and @ObjectState does this internally and base your implementation on that. (Or alternatively, ListReader and ObjectReader depending on your requirements)
I'm a little confused as to how to use this lib in a ViewModel SwiftUI context. I'd rather not have the View have a dependency on the CoreStore lib.
I'm not sure what to do with the snapshot and how to convert it to the @Published array. Will this array then be diffable? I'm more likely to map the objects to a detailedViewModel object. Something like:
I'm fundamentally not understanding how to get access to the Core Data objects from the listSnapshot.