Working with CoreData

[DavidKmn]

Was wondering on how you could see the architecture working with a more complex core data setup. I do know that core data supports using Combine with core data however it is still not so clear how to set up the dependencies in a nice way.

1. We need access to both the persistent store to create background contexts (for writing and then merging the changes into the main context) and a main context (for reading) would we keep these as environment dependencies or would we instead abstract these using a a struct based approach and create live version that would use core data under the hood? (A bit had to imagine how this could be setup)

2. Would we abstract the NSManageObject models or should these be ok to return from Effects? It's a good practice to work with NsManagedObjectIds for thread safety instead of passing around the objects, what are your thoughts on abstracting this? Or do you think it is reasonable to let core data specific things get out to the reducer level (meaning we would have to import CoreData and have a direct dependency at the reducer level)

3. In more complex setups there are a lot of different domain specific queries using NsPredicates, would this type of logic be living in the reducers or would you suggest preparing all the queries in advance and not working with NSPredicates directly (for example creating a client wrapper for each of the core data models and working directly with the client) in the reducers

4. Thoughts on willSave, didSave and didChange notifications and merging their changes into different interested contexts in the app.

[andreyz]

Personally I'd recommend modeling your app's data domain and then exposing it through a "store" in a classic definition of that name.

For example your app is an address book, so you'd have a ContactsStore. Which can be modeled as a TCA client (plain struct) that abstracts all CoreData mechanics and exposes only app's model objects (preferably plain value structs).

ContactsStore client will accept queries defined again in your app's domain terms, like fetchBirthdays or maybe you'll make your own query construct with enums.

[DavidKmn]

So is your suggestion to then have multiple "stores" for fetching data of different types (core data models). Let's say we have a simple chat application with 3 models we store in CoreData: Dialogs, Messages, Users. From your suggestion I gather you would have a UserStore, MessageStore, DialogStore with a struct abstraction for each. These would then in turn work direct with core data and also define "domain" models which essentially would just be wrapper models around NSManagedObjectModels and return these on methods such as fetchUsers. Is that the idea?

If so the next 2 questions are:

1. Does it make sense to just have 1 LocalDataStore instead with all of these requests instead of multiple model specific stores?
   This could simplify the logic since now we only need to have 1 env variable and pass that throughout the app. Also less code/definitions. However this does come with a drawback of exposing methods to features that may not necessarily have a need them. For example say we have a EditUserProfileFeature where we only want to pull data from from the current user meaning we don't care about dialogs or messages, but if we have just one giant definition of a store we get all of the unnecessary methods exposed.

2. If we do have 3 of these stores, does it make sense to have them all in separate modules (SPM) or would we have all of them in just 1 module (or 2 if we want to separate live and mock versions).

[andreyz]

I'm probably not the right person to answer your questions, as it is highly dependent on the codebase, of which you're the expert.

I'd pick choices that increase testability (that may or may not be separate store objects for each entity, but certainly plain structs over NSManagedObjects :)

If it's just couple of methods per model type, one store for all model types seems reasonable (and one SPM package), like the Isowords LocalDatabase client perhaps?

[buscarini]

Personally I would suggest moving away from CoreData. I've had only pain from it, and its problems are not solvable. The big issue is that it makes everything impure, if your model is based on ManagedObjects you don't control the model. You can't delete objects, every modification has to go in a specific thread, etc. If you still want to use it I would advice to restrict its use only to storing and loading data, and then converting it to and from structs.

[saroar]

same here I had so much pain to so I avoid for now with TCA :(