CoreData with TCA

[saroar]

I have created one open-source project for word learning and decided to use CoreData but not sure what is the best way so decided to share it here, so other dev can help and improve it.
so if anyone has time and like to help please download and run my app and advice how can improve it thanks 🙏🏾

https://github.com/saroar/Word369/tree/coreData

@tgrapperon here i am :)

[tgrapperon]

After at quick glance at your project, I don't know if CoreData is the best choice to manage your data: you have only one entity with not relationships. You're not using the main feature of CoreData which maintaining the coherence of your object's graph (because your don't need it), but you inherit many annoyances of CoreData (reference types, thread safety). You only get two useful things: some efficient memory management with faulting, and fast SQLite queries under the hood. These features are only coming in play when you have a lot of data entries. Maybe something like GRDB or SQLite.swift would be more convenient to use.

Proper CoreData handling with TCA is possible. The simplest way is to project your entity to a value type (like you did with Word). There are performance concerns, but it should work OK with a hundred entities or so. If you need to observe your context for changes, you can wrap your CoreData stack in some "controller"/"provider" type (like your WordRepository) which exposes publishers of Word (or [Word]), as well as CRUD APIs for Word. While doing so, you hide the fact that your store is backed with CoreData, and you can switch to another technology more easily. This is the approach I would recommend if the data's size allows it.
You can also observe the context from the environment and update your state accordingly. I wouldn't recommend doing so, as you would be tightly coupling your CoreData stack to your feature's domain, making refactors more cumbersome. This can be a solution however, if performance requires it.
Another idea with SwiftUI is to use a @FetchRequest property wrapper in your SwiftUI view to handle the fetch and the updates, and bubble up the results through the ViewStore to update your state in the reducer accordingly. It should work OK if your @FetchRequest is always active when you're interacting with your data. This is less convenient to test though.

I didn't look at the code thoroughly, but I'm seeing that you're instantiating NSManagedObjectContext yourself when setting up your WordRepository. When using a NSPersistentStoreContainer, you should use the viewContext property to get a main thread context associated with your store (and newBackgroundContext() to instantiate a background context). Your dependency is the NSPersistentStoreContainer (or something wrapping it like WordRepository). The managed object context is derived from it. You shouldn't furthermore use .privateQueueConcurrencyType (which means "background queue") for things you'll touch from TCA reducers (which are on the main thread most likely). This is possible, but it requires great care, and it serves no practical purpose here. If you're not familiar with CoreData, I would recommend to always use the main thread context to read and write. If performance requires it, you can opt-in later to make changes and saves on a background context (but you also need to switch to NSMergeByPropertyStoreTrumpMergePolicy instead of NSMergeByPropertyObjectTrumpMergePolicy to make your main thread context follow the store).

[tgrapperon]

I don't have any preference, as I'm not a heavy user of any of them. Both are very serious packages.
I would say that GRDB feels more approachable, and it would be likely the one I'd initially pick if I have to delve into, but I recommend to give a spin on a sample case to both of them to see how quickly you get something working and that you feel you understand.

[acosmicflamingo]

@saroar how did this work out for you? I'm now in the same position you're in, trying to integrate a database to my TCA music library app, and don't know what the best course of action is because many potential solutions seem quite incompatible with TCA out-of-the-box.

[Alex293]

GRDB can expose its data as publishers and/or async sequences. As it doesn’t provides something like auto updating models it’s quite adapted to TCA.

[acosmicflamingo]

@Alex293 Nice! Does look quite promising :) although it'd be nice for it to have CloudKit integration, I suppose I need to just take it one step at a time ;)

[Alex293]

Synchronisation really depend on your data but as GRDB is a fine layer above SQLite I think you can sync the database files directly. This won’t be fine grained though