Proof of Concept use compose for workflow logic

[japplin]

trafficstars

Not intended to be merged, just for easy viewing.

[steve-the-edwards]

I like the simplicity of this approach, and I think it will be even simpler after fixing the state issues I commented about.

One other general comment is that this creates a composable tree that is one giant recompose scope. As discussed in this blog post, only Composables that return Unit delineate recompose scopes. That means that, any time any of the workflows change state, the entire workflow tree will recompose. That matches the current behavior of the current workflow runtime. To fix this, a workflow would need to return a single rendering object backed by snapshot state, and do so in a way that breaks the direct return chain. I think you'd need to have two separate implementations of ComposeWorkflow to support both that and the current behavior.

I like the simplicity of this approach, and I think it will be even simpler after fixing the state issues I commented about.

One other general comment is that this creates a composable tree that is one giant recompose scope. As discussed in this blog post, only Composables that return Unit delineate recompose scopes. That means that, any time any of the workflows change state, the entire workflow tree will recompose. That matches the current behavior of the current workflow runtime. To fix this, a workflow would need to return a single rendering object backed by snapshot state, and do so in a way that breaks the direct return chain. I think you'd need to have two separate implementations of ComposeWorkflow to support both that and the current behavior.

@zach-klippenstein ~two~ three questions:

1. If there is only a 'single recompose scope' does that mean there are no optimizations done at all interior to that recompose scope based on the state tracking for other State objects?
2. If this is the case, since molecule is based on a @Composable() -> T driving a flow of T if any of the logic of what goes in to producing T (our RenderingT) in this case wants to be recomposed it should all return Unit and hoist the state it contributes back out to the root @Composable?
3. Also, in this case, if there is a child Composable in the tree that pulls in state from elsewhere would Compose 'start' the recomposition for it and then through the onValueChange for the hoisted state eventually recompose the root?