Advice for workflows with dynamic content based on input

[zoltish]

Please consider a scenario where one workflow renders a screen (A) that in turn has a backstack of screens (B and C). The root workflow renders A and handles its outputs accordingly.

This is all fine, until I decide to make life complicated by allowing the parent workflows to control which screen A starts at, and whether it should be able show screen B at all.

Now Ive ended up in a situation where A:s outputs involve B:s outputs, despite it in some scenarios never rendering B at all. I know that this is the case, so when Root renders A, I can simply do "when output is from B, ignore it because it will never happen" but that seems very bad to do in a large codebase with multiple coders.

How would you approach this?

My thought so far:

• Allow B and C to be rendered as standalone screens, specifying if theyre embedded or not. Basically making them do what A does if they arent embedded; but Id hate to put all of that logic in 2+ places.
• Provide all the output handling for each screen in the input props that A receives. This seems OK-ish and typesafe, just seems like a weird thing to do and involves a lot of extra boilerplate.

[rjrjr]

It's such an abstract framing that I'm having a difficult time answering. Maybe you could reply with the real names of Root, A, B and C and their outputs?

A few thoughts that do occur to me:

when Root renders A, I can simply do "when output is from B, ignore it because it will never happen"

I would throw in a situation like that. Rather than, "ignore it because it will never happen," throw because "uh oh, this should never happen!" https://en.wikipedia.org/wiki/Fail-fast. And perhaps that check can be less about "I started A in SkipB mode" and more about "In this state, or according to this model object, I already know fact ReportViaBOutput, I should not receive this event a second time."

With all this anxiety around the flow of outputs, is there perhaps a shared injected model object that is missing? Rather than B and C posting outputs, should they be changing the state of an injected FooModel that Root monitors directly in embedded situations?

[zoltish]

Sorry about the abstractness, Ill share some more details below.

• (A) WizardWorkflow is the "container" workflow that handles transitioning between B and C
• (B) SelectorWorkflow has a '+' that always leads to...
• (C) CreatorWorkflow, which has an optional back button if navigated to from B

In practice, A puts the content in a ModalBottomSheet (compose) and then does some fancy animations between B and C. Usually the content starts at B, but in some cases .. its only C. The root workflow is really any parent, all of the outputs are handled locally.

Agreed about throwing an exception over ignoring. Overall I dont like to have open ends like this as it makes wrong logic possible, and that almost always leads to bugs sooner or later.

In response to your other comment: I actually found that it wasnt all that awkward to include the necessary information directly in the input props. It just breaks the normal logic Im used to follow, i.e. the outputs callback from a workflow contains all the outputs, this way Ive got outputs in parameters I specify in the input. But as long as I keep the parameters minimal, it seems OK.

[rjrjr]

CreatorWorkflow, which has an optional back button if navigated to from B

We always treat this kind of thing as a view concern, and keep our workflows/controller/presenter code out of the loop. In fact this use case is the exact reason that we introduced ViewEnvironment, along with BackStackConfig as the very first ViewEnvironmentKey.

We frequently have things like CreatorWorkflow that sometimes are used in the middle of a wizard-style backstack nav set, but sometimes are the first entry. In these cases, the CreatorScreen : Screen rendering is always provided with an onGoBack event handler, which always results in a CreatorWorkflow.Outputs.GoBack output event. It is up to the view code to decide if it's running in a context where it should actually show its back button:

    val showBackButton = viewEnvironment[BackStackConfig] == BackStackConfig.Other

Maybe you could do something similar.

[zoltish]

Agreed about it being a view concern. Ultimately I think Im doing something very similar - without the ViewEnvironment (this is a great example of why the ViewEnvironment can help make life easier though).

Overall quite happy with the solution: passing handlers as input rather than handling the output works! It also helps that I managed to reduce the input parameters from 5 to 2, so it doesnt feel like a ton of boilerplate everywhere I use these workflows. I dont think theres anything additional that needs to be done, but if another solution comes to mind - Id love to hear it!

[zoltish]

@rjrjr Sorry to bring this up again, I was just curious to hear your thoughts on storing event handlers in states of other workflows, very very bad idea, or OK-ish?

Some context -> The wizard workflow "output" has 2 outcomes: (1) it modifies the global state; or (2) it modifies the parent workflows state. Given this, I think the approach chosen is correct since the wizard doesnt need to know how its output is handled, it just sends it. Im using this workflow a lot (7 places, probably 9 in total when Im done) and it has made me wonder if theres a better approach I can use.

The only other solution that comes to mind is effectively storing the "output" handlers in state of my root workflow: I have a router that is injected into my workflows, it basically narrows the gap between root <> deep child workflows so that I dont need to propagate some common outputs throughout the entire chain of workflows. The root workflow handles rendering some of the main/big features of my application and observes the router to handle navigation between them.

This works great, and the only other solution I mentioned is just that - instead of rendering the wizard everywhere, let the root workflow render it like the many other features. To make that possible, Id need to store how the child workflow wants to handle the output in the root state (imagine it having a List where WizardRoute would then have val onOutput: (X) -> Unit). This doesnt hit me like the best idea, but I still thought Id at least check for your opinion on it. Since there are N situations where the wizard is rendered, I dont think I can move the output handling logic elsewhere "outside" of the inner workflows.

[rjrjr]

My kneejerk is against it, because it reminds me of the "multihoming" pain point of our previous system which was one of the biggest inspirations for creating workflow. Being able to run shared subflows like the wizard you're describing under multiple parents was our primary driving use case. I don't know that that means I'm right, though. It's just the history, and my reaction could mean more about where the scars are than evidence this is a bad idea. I guess I'd ask, if "this works great," why mess?

WRT the specific question you asked, storing event handlers in state, it depends on what exactly you mean. If you're talking about invoking an event handler on the rendering of one workflow from a side effect or Worker of another Workflow, be warned that #1093 means this can lead to situations where a side effect or worker might never be invoked.

[zoltish]

Same same, Ive tried my hardest to make it work using "classical" systems before, but all I ever got back was pain and bugs.

Almost ironically though, I recently realized that I actually want the wizard to control some centralized state, so I ended up making it a "top tier" citizen, and just rendering it as part of the root workflow like any other feature. I guess when things get complicated like what spurred this discussion, the issue is most often elsewhere. You even hinted at it previously, but I couldnt zoom out enough to understand that you were right (thank you):

With all this anxiety around the flow of outputs, is there perhaps a shared injected model object that is missing? Rather than B and C posting outputs, should they be changing the state of an injected FooModel that Root monitors directly in embedded situations?

[rjrjr]

Provide all the output handling for each screen in the input props that A receives. This seems OK-ish and typesafe, just seems like a weird thing to do and involves a lot of extra boilerplate.

That doesn't seem like a terrible idea on its face, and is close to my notion of injecting a model object.