SwiftUI @Published ViewModel example #411

New Issue

Open

opened 2025-12-29 15:31:09 +01:00 by adam · 7 comments

adam commented 2025-12-29 15:31:09 +01:00

Owner

Copy Link

Copy Source

Originally created by @elprl on GitHub (May 3, 2023).

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.

Originally created by @elprl on GitHub (May 3, 2023). 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. ```swift 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: ```swift 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.

adam commented 2025-12-29 15:31:09 +01:00

Author

Owner

Copy Link

Copy Source

@elprl commented on GitHub (May 4, 2023):

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.

@elprl commented on GitHub (May 4, 2023): Update: I managed to get access to the Core Data objects in the snapshot via: ```swift itemsSnapshot.compactMap { $0.object } ``` Not mentioned in the docs, so not sure if this is a good tactic.

adam commented 2025-12-29 15:31:10 +01:00

Author

Owner

Copy Link

Copy Source

@JohnEstropia commented on GitHub (May 9, 2023):

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

@JohnEstropia commented on GitHub (May 9, 2023): 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

adam commented 2025-12-29 15:31:10 +01:00

Author

Owner

Copy Link

Copy Source

@elprl commented on GitHub (May 9, 2023):

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.

@elprl commented on GitHub (May 9, 2023): 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. ```swift 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.

adam commented 2025-12-29 15:31:11 +01:00

Author

Owner

Copy Link

Copy Source

@JohnEstropia commented on GitHub (May 10, 2023):

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 commented on GitHub (May 10, 2023): 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.

adam commented 2025-12-29 15:31:11 +01:00

Author

Owner

Copy Link

Copy Source

@JohnEstropia commented on GitHub (May 10, 2023):

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.

@JohnEstropia commented on GitHub (May 10, 2023): > 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 `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.

adam commented 2025-12-29 15:31:15 +01:00

Author

Owner

Copy Link

Copy Source

@elprl commented on GitHub (May 10, 2023):

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

@elprl commented on GitHub (May 10, 2023): 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: ```swift 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) } } ```

adam commented 2025-12-29 15:31:15 +01:00

Author

Owner

Copy Link

Copy Source

@JohnEstropia commented on GitHub (May 11, 2023):

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)

@JohnEstropia commented on GitHub (May 11, 2023): 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](https://www.donnywals.com/observing-changes-to-managed-objects-across-contexts-with-combine/) is already provided in CoreStore's `@ListState` and `@ObjectState` and are ready to be used in SwiftUI projects. (see [Modern.ColorsDemo.SwiftUI.ListView.swift](https://github.com/JohnEstropia/CoreStore/blob/25593754913d228777f14634bc6f493dbeb4e9fb/Demo/Sources/Demos/Modern/ColorsDemo/Modern.ColorsDemo.SwiftUI.ListView.swift#L19) and [Modern.ColorsDemo.SwiftUI.DetailView.swift](https://github.com/JohnEstropia/CoreStore/blob/25593754913d228777f14634bc6f493dbeb4e9fb/Demo/Sources/Demos/Modern/ColorsDemo/Modern.ColorsDemo.SwiftUI.DetailView.swift#L20) 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](https://github.com/JohnEstropia/CoreStore/blob/25593754913d228777f14634bc6f493dbeb4e9fb/Sources/ListState.swift#L38) and [@ObjectState](https://github.com/JohnEstropia/CoreStore/blob/25593754913d228777f14634bc6f493dbeb4e9fb/Sources/ObjectState.swift#L38) does this internally and base your implementation on that. (Or alternatively, [ListReader](https://github.com/JohnEstropia/CoreStore/blob/25593754913d228777f14634bc6f493dbeb4e9fb/Sources/ListReader.swift) and [ObjectReader](https://github.com/JohnEstropia/CoreStore/blob/25593754913d228777f14634bc6f493dbeb4e9fb/Sources/ObjectReader.swift) depending on your requirements)

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

develop

prototype/swift6

master

prototype/concurrency

minIOS13

prototype/containers

transactionSourceTracking

prototype/swiftui

minIOS11

swift5_3

prototype/propertyWrapperFields

prototype/propertyWrappers

prototype/propertyWrapper

Swift5

throwables

prototype/Swift_4_1

prototype/Swift_4_0

prototype/Swift_3_2

prototype/queryBuilders

temp/develop

corestore4_develop

prototype/mainContextToPSC

master_ios_7_to_9

swift_2_3

gh-pages

_corespotlight-test

9.3.0

9.2.0

9.1.0

9.0.0

8.1.0

8.0.1

8.0.0

7.3.1

7.3.0

7.2.0

7.1.0

7.0.4

7.0.3

7.0.2

7.0.1

7.0.0

6.3.2

6.3.1

6.3.0

6.2.1

6.2.0

6.1.0

6.0.0

5.3.1

5.3.0

5.2.0

5.1.1

5.1.0

5.0.0

4.2.4

4.2.3

4.2.2

4.2.1

4.2.0

4.1.4

4.1.3

4.1.1

4.1.0

4.0.5

4.0.4

4.0.3

4.0.2

4.0.1

4.0.0

4.0.0-beta3

4.0.0-beta2

4.0.0-beta

3.1.1

3.1.0

3.0.3

3.0.2

3.0.1

3.0.0

2.1.3

2.1.2

2.1.1

2.1.0

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

1.6.10

1.6.9

1.6.8

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.1

1.2.0

1.0.2

1.0.1

1.0.0

0.2.1

0.2.0

0.1.2

0.1.1

0.1.0

Labels

Clear labels

abandoned

corestore bug

discussion

duplicate

enhancement

fixed

fixed

help wanted

in progress

investigating

ios/compiler bug

irreproducible

looking for workarounds

not a bug

pending

pending docs update

pull-request

Mirrored from GitHub Pull Request

question

regression

user bug

wontfix

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

adam (Adam Melkus)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/CoreStore#411