How do you recommend handling "sticky" states for returning workflows?

[zoltish]

Consider a scenario where a workflow renders child A or B, where B also renders C.

Id like to keep the state of C around, but when switching between A and B, a new node will be created for C everytime a new one is created for B, and Im assuming that C will start from a fresh state everytime?

First of all, is this assumption correct, or does the snapshot system support cases like this such that C can at least snapshot its state and regain those bits at a later point in time?

If my assumption is correct, how would you recommend handling situations like this? I can tell that the BackStackScreen and its usage provides a way for a stack of screens to retain their states, but that approach seems awkward for situations like this (in practice, the chain of workflows might be much deeper than just A>B>C, which would make it awkard for every workflow to continue rendering a nested workflow when its not actually used at the time).

[rjrjr]

Your assumption is correct. Snapshots only come into play on the very first render pass, and are intended for reviving the entire tree -- say in a new process.

What I've done in situations like this is have C provide a continuation object as output (could be its entire state object, could be just enough info to resume), and accept the same as an optional part of its props, or as a constructor argument for its factory. This would require the parent of A to be in on the game. C emits to A emits to root, and root kicks off B w/the required info to keep C going.

Another possibility is for root to run all three of A, B and C directly, and stitch their renderings together. You could pass C's rendering as props to A & B. Or have A & B leave holes in their renderings that root fills w/C's rendering. That's probably how I'd do it, since it leaves A B & C uncoupled.