SwiftUI @Published ViewModel example

[elprl]

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.

import SwiftUI
import CoreData
import Combine

struct ContentView: View {
    @StateObject var viewModel = ViewModel()
    var body: some View {
        List {
            ForEach(viewModel.items) { item in
                Text("Item at \(item.timestamp!)")
            }
        }
        .task {
            viewModel.setupItemsListener()
        }
    }
}

import CoreStore

class ViewModel: ObservableObject {
    private let dataStack = DataStack(xcodeModelName: "CoreStoreTestHarness")
    private var cancellables: Set<AnyCancellable> = []
    @Published var items: [Item] = []
    
    func setupItemsListener() {
        let listPublisher = dataStack.publishList(
            From<Item>()
                .orderBy(.ascending(\.timestamp))
        )
        listPublisher.reactive
            .snapshot(emitInitialValue: true)
            .receive(on: RunLoop.main)
            .sink(receiveCompletion: { completion in
                switch completion {
                case .finished:
                    print("getItems receiveCompletion finished successfully")
                case .failure(let error):
                    print("getItems caught error \(error)")
                }
            }, receiveValue: { [weak self] itemsSnapshot in
                print("getItems receiveValue")
//                self?.items = itemsSnapshot // what do I do here?
            })
            .store(in: &cancellables)
    }
}

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:

        listPublisher.reactive
            .snapshot(emitInitialValue: true)
            .compactMap { DetailedViewModel(item: $0.value ) } // what do I do here?

I'm fundamentally not understanding how to get access to the Core Data objects from the listSnapshot.

[elprl]

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.

[JohnEstropia]

Hi, have you checked the CoreStoreDemo project? There are examples on how to use ListPublishers in tandem with ListReaders and ObjectReaders depending on whether you need ObjectPublishers or ObjectSnapshots in your SwiftUI Views

[elprl]

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.

[JohnEstropia]

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 Views 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.

[JohnEstropia]

I'm not sure how you'd even use .object without depending on CoreStore, because that object is of CoreStoreObject type anyway

Ah, I guess you are using NSManagedObjects directly instead of CoreStoreObjects. Nevertheless, you will still be better off using the right wrappers (ObjectPublisher or ObjectSnapshot) to properly sync your views.

[elprl]

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)
    }
}

[JohnEstropia]

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 Views 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)