<@U0KMMQA20> I've been testing the workflow sample...

# squarelibraries

[leodeleon]

@Zach Klippenstein (he/him) [MOD] I've been testing the workflow samples and I can't wrap my head around one thing.
I see that the screen types can be used as the rendering of a workflow, and that the lib provides (and we can create) different types of screens to be interpreted differently by the api (e.g. BackstackScreen)
Is there a way to abstract this concept when modelling the renderings. When do I know I can/need to create a different screen rendering type, and how should I go about it in a way that exposes itself to Android later? Examples are PanelContainerScreen and ScrimContainerScreen.
https://github.com/square/workflow/tree/4172907790c30385c8b57b5f3009351ff4d50cc8/kotlin/samples/containers/common/src/main/java/com/squareup/sample/container/panel
In other words, how should one model rendering types and how to make sense of it in the context of a workflow?

[Zach Klippenstein (he/him) [MOD]]

We usually think about renderings as one concrete rendering type + LayoutRunner per logical screen. But that's just a convention and a starting point.

If a screen is really complex, sometimes it helps to factor parts into child workflows with their own `LayoutRunner`s. Eg if you have some data entry form component that has validation logic and is used in different parts of your app, it might make sense to give that form its own `LayoutRunner`+`Workflow`+`Rendering`, and then any workflow that needs to use it just renders the workflow, puts the child rendering in its own rendering, and uses WorkflowViewStub to display the rendering.