ViewEnvironment, for Workflows?!

[zoltish]

Hey!

So this idea just came to me because I was thinking about ViewEnvironment and how it allowed you to pass down values to nested screens. Kind of like how CompositionLocal works in compose?

Then I checked out the code and saw that its actually UI related (doh, the name does state View even). Anyhow, the reason I was thinking about this:

If I have a repository.profile(): Flow<Profile> that I use in say 15 workflows. Then in each of those, I need to have state.profile, and setup the query for the profile, and potentially show loading if the profile hasnt been fetched yet. This leaves me feeling like theres got to be a better way, but also considering how CompositionLocals in compose are (for many at least) considered evil because of how hard they make tracing your code.

So with that said, remove the view from ViewEnvironment and you have Environment. This is something that I suppose would live in the context, so you can do context[ProfileKey] or something akin to that. I think this would be amazing, because if you have a promise of a non null value, then you - or me, in my case - get to query the profile in my root workflow, show loading until its ready, then pass it downstream! And in every nested workflow, I can just do context[ProfileKey] to get it.

Downsides?

• I have to adhere to the promise, if the profile is not passed down I get a crash at runtime.
• Same as with CompositionLocals, super powerful but harder to trace code.
• In terms of implementation, it might be hard to reason about what to invalidate when the value of a key changes.

Happy to see some discussions around this!

[rjrjr]

This comes up a lot. We actually don't want something like ViewEnvironment for the workflow runtime because it's a poor solution for the kinds of problems that are solved very well by DI systems like Metro, Dagger/Anvil or Hilt. An environment approach would encourage creating hard to debug runtime problems that are much better handled at compile time by libraries like those.

[zoltish]

Thanks for getting back to me! I agree with you, and just so that I get what you mean by using DI for this... do you mean injecting say ProfileService into all of these classes and then doing something akin to profileService.query(); and putting the profile in the state, etc? This is pretty much what Im doing currently, w/ a cache so that I dont just fetch it over and over.

[rjrjr]

Yes-ish. Having to inject it in so many places is a bit suspicious and can be inefficient, although we're working on an optimization to improve exactly that concern, see #1355.

If you're in a situation where that flow on the ProfileService might be consumed in N live workflows at once, and the new DRAIN_EXCLUSIVE_ACTIONS optimization is disabled, then when the flow emits you'll get N render passes in a row. The optimization is able to recognize when several subtrees are dirtied at once and can update them all in a single render pass.

Otherwise if you're in that situation and have convinced yourself it's worth addressing, consuming the flow in a single ancestor and passing the data through children via PropsT really is the only alternative.

One way to make that a bit nicer is to create an interface to be implemented by the workflows that rely on that info, e.g.

interface WithProfile {
  val profile: Profile
}

interface ProfileWorkflow<P : WithProfile, O, R> : Workflow<P, O, R>

So you still have to write the code that passes it though props, but at least you can have a convention that makes the concern a bit clearer and lets the compiler help you follow the rules.

[zoltish]

The optimization is very neat for cases like this!

Prop drilling is okay I think, the main thing that stands out and prevents me from doing it in this case is that many of these workflows have workflows betweem them and the root one (where profile would be queried & passed down).

Ive had similar issues in the past where Ive wanted to emit an output from a child workflow, say 4 levels deep, to the root one. Its an easier problem to solve though - I just implemented a sort of router that takes actions and emits them, so emitting an action from the child workflow, and observing it in the root one.