Recommended way to incorporate local persistence updating and observing?

[NickvanDyke]

Per React, when two children need to display and update common data, they delegate the updating to their closest common ancestor, and receive updates from said common ancestor https://reactjs.org/docs/lifting-state-up.html

How does the addition of a database, which can be thought of as global state, work into this? Since local persistence is much less common in the web compared to mobile world, I couldn't find anything about how to treat it in React; my apologies if my question has already been answered. I also didn't see any local persistence in the sample apps.

• Since this database can act as a shared state between the children, should they just update and observe it themselves, circumventing communicating through the parent workflow completely?
• If they should still "lift state" and delegate to the parent, should the parent:
  • Update its state, and update the database so it reflects the Workflow's state
  • Update the database, and then query it, using the results to update its state (seems like the most pure functional approach)
  • Always observe the database, and when instructed to update state, the parent updates the database, which then causes an emission, which the parent reacts to and updates its state with

Lastly, regardless of whether it's done in the child or parent, what's the recommended way to do this database updating in Workflows? It seems excessive and overly verbose to have an explicit state or field UpdatingRecords in which we're running a worker that will perform the db update on a different dispatcher. It also might get messy if we have to perform/queue many updates. But is that still the best approach? Or should we have an action that launches a coroutine w/ IO dispatcher that updates the db, without setting nextState or setOutput()? If the latter, is there a CoroutineScope whose lifecycle matches that of the Workflow? Workflow doesn't have a callback or indicator for when it's being stopped (as far as I could tell), so we can't use that to cancel a scope managed by the Workflow. Would GlobalScope be acceptable?

[zach-klippenstein]

Lifting state: generally a good thing, as it makes the children workflows more testable and reusable.

Updating DB: I would recommend your third bullet point. It works great with SqlDelight/Room, Dropbox Store, etc.

How to do side effects: Use Workers, which effectively give you a coroutine that is scoped to the workflow. It's not released yet (should be within the week) but we just introduced a more fundamental primitive for side effects, see runningSideEffect, which is the workflow equivalent of something like Compose's launchInComposition.

[NickvanDyke]

Thank you, I appreciate the guidance.

If we're to update the database from a worker (for which the runningSideEffect seems much more convenient, thanks for that), that means we need to store what's being updated and how in the state, to pass to the worker/side effect. How would that best be done? A field in the state akin to queuedUpdates: List<UpdateData>? And then use collectToSink within the side effect to emit an action that will remove the queued update from the state? Or do Workflows guarantee some order of operations such that the field can be singular as opposed to a list, and if many state-changes with that db update field set all come in quick succession, all the db updates will be executed in order?

Semi-related question - since a full-fledged Worker and runningSideEffect have the same capability - do some work outside the workflow and potentially trigger state updates (although side effects can emit an action directly, and workers emit a result that the workflow potentially maps to an action) - when should we prefer each one?

[zach-klippenstein]

I would probably lean towards using runningSideEffect if it meets your needs, i.e. your doing work inline. Workers are a little simpler if you already have a stream, since you can just call .asWorker().

I think you're on the right track with storing a list of updates in the state. Every time an update finishes, a WorkflowAction should remove that update from the list. The library doesn't do any serializing of tasks for you, if you want to execute tasks serially instead of concurrently, you need to implement that yourself (e.g. by using a queue in your state).

[zach-klippenstein]

Closing since there's been no activity in a few days, feel free to re-open if you have more to discuss.