I’m scoping out a persistence dependency to use with a TCA prototype and had a question regarding the sequence of state mutation and persistence. There are two options as far as I can see:
New value > write to store via effect > send Action to Store > mutates state
New value > mutate state > Action which persists new value
It’s worth noting the plan is to eventually have multiple devices accessing a common persistent store of data so I’d want mutations to the central repository to be pushed to all connected devices.
Although option 2 would seem to be the more canonical approach (state mutation takes place before Effects), if the app terminates unexpectedly before the persistence takes place there could be data loss. The data being stored is clinical and therefore an accurate persisted record is very important and, as noted above, the single source of truth should (eventually) be the central repository (not decided on the provider here yet). Am I worrying unnecessarily or is there a happy path here?
On a related subject is there any reliable way of detecting an exception/unexpected app termination and persisting unwritten state to store? I’ve implemented some “middleware” that I use to monitor the app lifecycle (as reported by NotificationCenter) but I’m not really sure if that is the correct tool for the job.