Advice for flexible nested workflow renderings

[zoltish]

I have a workflow that Id like to render in two places, but Im having a hard time figuring out how I can make it happen due to the renderings being 'Any' (LoadingScreen, followed by FooScreen) and there being some optional functionality that only one of the places should include.

1. I can ditch the default rendering, so the workflow just renders a sealed class of FooLoading and FooScreen(data) which the parent workflow places somewhere in its screen, and the UI eventually adding all the elements to its list. Due to all the default behavior, this would mean rewriting the same functionality in both places (e.g. when this is clicked, send event X, etc etc, but the child workflow could at least handle the events in both scenarios).

2. I can try to include all the flexible functionality as input parameters of some kind, the workflow would then know about all the functionality and only include that which is specified in the input (the output would probably be "wrong" in the sense that you might get a FooOutput which you just specified can never happen in the input). This also seems rough because the rendering is placed inside a nested list, so you would have a list with a list, and it would break.

3. Are there any other options?

[rjrjr]

This is kind of hard to answer in the abstract, especially the bit about lists. Is there a PR you can share, or maybe you can post a gist?

[zoltish]

Thats understandable. I dont think I can share the actual code, how about a screenshot of the screens interaction?

The top bar and tabs are part of the exercise-flow, and the list is part of a history-flow, the latter is what Id like to re-use in another scenario. It works great in this scenario since the entire content of the page is the history rendering, and it has no additional functionality beyond the default (e.g. you can click the date to view the details of that workout, etc).

In the other scenario however (training-flow); the content of its page is a list with other ui elements, and it should pretty much append the history-flows rendering onto its own list, with additional funcionality (e.g. more click events) on top of the defaults. Its impossible to embed the renderings (FooLoading + FooScreen) since it would lead to a list with another loading/list inside of it.

I dont know if this makes more sense, fingers crossed that it does :) The question really is how I can include dynamic list renderings inside other lists. Should the history renderings be typed such that both flows can interpret them and do their own thing with it? In the past Ive simply duplicated logic for cases like this, but as more and more logic is added in, the burden is ever increasing.

[rjrjr]

So you're mainly concerned with sharing the view code that displayes the history list and wires up event handlers, with the new location wanting to make it richer, yeah? The sealed class approach you put up as option 1 sounds pretty sane to me — make RenderingT a more public concern so that parent worklfows have the option of messing with it, can choose how to reflect the loading state, etc.

I suspect the duplication won't be all that big a deal. If you're using RecyclerView to show the combined lists, you'd likely want pretty different treatment than in the vanilla case anyway -- have to map indices, who knows what else.

[zoltish]

Well, it definitely works! I just had to change the RenderingT from Any to LoadingScreen for the other flow to recognize it.

The views are supposed to be almost identical, with the aforementioned tweaks between them; I feel like I still lose out on that - I will inevitably end up writing the same code for the views in two places (wrapping each list element in a card, adding some extra listener where applicable, etc), whereas the workflow really only loads some data and organizes it ever so slightly.

I wonder if theres a sane way to share the view logic between the two? Im using compose, and perhaps this is a really really bad idea, but I could provide access to the parent LazyListScope through a CompositionLocal, that way the items would just get appended and there wouldnt be two lists. Im not sure how that would actually behave in practice though! In the same manner, further view configurations would be provided through the same CompositionLocal, e.g. WrapInCard, ItemOnClickListener, etc, etc. Perhaps its easier to just accept the duplicated view logic.