Introduce ComposeWorkflow, a self-rendering Workflow.

[zach-klippenstein]

ComposeWorkflow is kind of like a StatelessWorkflow, but it has a special render method:
it's a @Composable function, and it functions like the body of a bindCompose lambda
where the rendering is just the workflow's props and a Sink accepting OutputTs. It cannot render children or run workflows, although it can use Compose's own facilities for subscribing to observable streams, models, etc. It does not have state in the StateT workflow sense, but it can also use Compose's state management facilities.

This is more a proof-of-concept than anything, it probably encourages bad code. But, it might be useful for libraries that want to provide small self-contained components (e.g. a date picker).

I implemented that Hello Compose sample as a self-rendered workflow, it looks like this:

object HelloRenderingWorkflow : ComposeWorkflow<String, Toggle>() {

  object Toggle

  @Composable override fun render(
    props: String,
    outputSink: Sink<Toggle>,
    viewEnvironment: ViewEnvironment
  ) {
    MaterialTheme {
      Clickable(
          onClick = { outputSink.send(Toggle) },
          modifier = Modifier.ripple(bounded = true)
              .fillMaxSize()
      ) {
        Text(props, modifier = Modifier.wrapContentSize(Alignment.Center))
      }
    }
  }
}

And it's rendered just like any other workflow, i.e.

context.renderChild(HelloRenderingWorkflow, "Text") { onToggle() }

[rjrjr]

Could be a really nice alternative to ViewRegistry, if a team could maintain discipline about logic workflows v. UI workflows. Big if, though.

[zach-klippenstein]

The main thing that ViewRegistry solves is that it allows view factories to display arbitrary renderings without knowing about all the rendering types itself. It's a lookup. This doesn't do any of that.

If anything, this could replace WorkflowLayout by wrapping the root workflow in one that delegates to a ComposeWorkflow to invoke the view registry. We'd still need some top-level wiring to actually get the composable on the screen, but there might be some benefit to making the entire rendering-to-views integration just a single wrapper workflow. In this world, setContentWorkflow could just require the root workflow's rendering type to be ComposeRendering, maybe with an overload that automatically wraps workflows with other rendering types in one that just delegates directly to the ViewRegistry. As I am typing this paragraph I am liking this idea more and more.

This is all academic at this point though since compose doesn't yet fully support nesting Android views in Composables.

[zach-klippenstein]

Ray approves, and while I am slightly reluctant to merge, I think now that this is in a separate, is super experimental and doesn't imply the "official best practices" of the main workflow repo, I don't think it hurts to have stuff like this here. Lets us experiment, and if it turns out to be a bad idea we can remove it.

[zach-klippenstein]

Ugh, merged into a branch again. Reset that branch, and will merge this into master once that lands.