Introduce WorkflowContainer for running a workflow inside a Compose app.

[zach-klippenstein]

This is the third flavor of integration, it replaces setContentWorkflow, WorkflowLayout, WorkflowRunnerViewModel, etc., and makes it really easy to run a Workflow inside a pure Compose app. It's compatible with ViewEnvironment/ViewRegistry, but doesn't require it – it gives you the root rendering, and you can do whatever you want with it.

It also supports running root ComposeWorkflows directly, since they are self-rendering.

@Composable fun App() {
  val counterWorkflow: Workflow<Duration, Nothing, Int> = remember { … }

  MaterialTheme {
    WorkflowContainer(
        workflow = counterWorkflow,
        props = 1.second
    ) { counterValue ->
      Text("Counter: $counterValue")
    }
  }
}

You can also use a ViewRegistry, but it's entirely optional and there's no special API for it:

private val viewRegistry = ViewRegistry(
  FooScreenFactory,
  BarScreenFactory
)

@Composable fun App(onFinished: () -> Unit) {
  val viewEnvironment = remember { ViewEnvironment(viewRegistry) }

  WorkflowContainer(
    workflow = RootWorkflow,
    onOutput = { onFinished() }
  ) { rendering ->
    viewEnvironment.showRendering(rendering)
  }
}

[rjrjr]

Did you really expect me to say "hold up there pal, too many overloads"? I really like it.

!

[zach-klippenstein]

What about the name, WorkflowContainer? Feels a bit clunky to me. For comparison, SwiftUI Workflow integration went with WorkflowView, which I don't think is a great fit here because compose generally doesn't use the term "view" so it would be unidiomatic and probably confusing.

Maybe this should even be an extension on Workflow, like:

@Composable fun App() {
  MyWorkflow.render(props) { rendering ->

Or even (and this is more consistent with Flow.collectAsState)

@Composable fun App() {
  val rendering: State<Foo> = MyWorkflow.renderAsState(props)
  // and we get this sugar for free
  val rendering: Foo by MyWorkflow.renderAsState(props)

The return-value and lambda versions could also both live together. I will rename observeWorkflow to the second one anyway, even if we don't expose it as public API.

Asking for thoughts on the Kotlin slack too.

[zach-klippenstein]

Needs tests in core-compose.

[zach-klippenstein]

This isn't applying the ComposeViewFactoryRoot. Since we're already in Compose land, it's not necessary to use that tool, but we should still handle that case correctly. Needs a test as well.

[zach-klippenstein]

Also, this should be applied in the non-ComposeWorkflow case as well. That's going to require changing that function to accept a ViewEnvironment, which is too bad. We could make ComposeViewFactory responsible about automatically applying the root wrapper. Going to do this in a separate PR first as a follow-up.

[zach-klippenstein]

I'm happy to leave bikeshedding the name for later. (#22)

[zach-klippenstein]

Added a bunch of tests, addressed the merge blockers.

[zach-klippenstein]

Github Actions run failed:

An unexpected error occurred when executing this workflow. Please submit a new support request using our Support website:

https://support.github.com/contact

Please include this unique ID in your request: 9939:14F5:1AC915:1CB144:5EBEFA7F

Pushing a new commit to try again…

[zach-klippenstein]

Actions failed again (second ID is 851B:6485:6C603:77E59:5EBEFCF5).

[zach-klippenstein]

https://www.githubstatus.com shows issues.