Understanding the added benefit of workflows over just using compose

[zoltish]

Ever since compose became beta ready Ive been asking myself whether there is a real purpose to a separate state machine; doesnt compose solve the same issue? Is this something youve been discussing yourselves, and if so: where have you landed? Ive seen that you have support for compose, but then again - isnt it easier to create a state machine with compose and declare the actual compose-views there too?

From my own musings, I think a separate state machine makes it easier to support multiplatform (but compose might support that, as well); Im also using them in android services for various tasks, which I think wouldnt be possible with strictly compose. On the other hand, declaring a render/screen and then binding the actual ui widgets to the fields in it somewhere else .. can be positive, you can definitely use it in different UI:s; but for me personally I always feel the overhead of doing all the extra binding work, whereas compose just does it for you, or at least makes it way shorter & easier to do so.

Id love to hear your thoughts. Im just trying to get a feel for what compose actually delivers over state machines (that produce UI).

[rjrjr]

I should really let @zach-klippenstein answer this, as I'm not all that fluent yet in Compose, but I'll give it a shot anyway. I think the strict compile time safety that Workflow state machines provide fill an important gap left by Compose. In our apps this is demonstrated in part the increasing number of "headless" workflows we write to drive service interfaces.

I don't know that the verbosity of Workflow is what we would have built from scratch had Compose been ready when we needed it, especially given the Compose core's clean separation from both UI concerns and Android. There are some tantalizing sketches in the works of other possible approaches, like Zach's ComposeModel. But Workflow is solid now, and IMHO a great source of models to be rendered by a Compose app.

[zach-klippenstein]

I think about this a lot!

Workflow has a couple primary design goals:

1. Allow business logic to be separated from UI, while still driving things like navigation which are often BL concerns.
2. Encourage writing logic in terms of explicit state machines – that is, state is an explicit entity that is mutated atomically by explicit actions.
3. Different parts of business logic should be self-contained, have clear APIs, and be re-usable in different parts of the app ("composable").
4. Favor explicitness over "magic" – while magic makes for cool demos, it makes a large codebase unmaintainable.

Workflow started out as a design pattern, and eventually crystalized into actual implementations with common APIs. It is definitely possible to solve all of these things with other architectures and patterns (e.g. AndroidX ViewModels, Redux, MVI, Decompose, Mavericks). I've explored building workflow shapes using Compose features to clean up the syntax. There are some use cases that would have been unfeasible to solve with Views that are much more approachable with Compose and for which, while in the old world Workflow might have solved a real problem, it no longer does and is just over-engineered.

I think the immediate future of Workflow is probably fairly set at this point, with Compose taking over for the view layer. Longer-term though, if I were starting an app from scratch, I would probably trying to apply the same principles that inspired Workflow to simpler solutions that leverage the power, flexibility, and expressiveness of Compose. For example, I would still probably want explicit state machines, clearly separated from the view layer. This is what that compose-model experiment was playing with.

There are a few details about Workflow that we focused on pretty hard early on, such as ensuring that every state transition gets rendered 1-to-1, not syncing render passes to vsync, etc, that prevent certain optimizations and in particular that Compose is specifically to take advantage of in order to provide better performance. Unfortunately we don't have really solid data on how helpful these constraints have actually been in the real world. My guess is that we may have over-estimated their importance, and we'd be no worse off making the tradeoffs that Compose did instead.

[zoltish]

Thank you both for taking the time to respond!

@rjrjr If I understood you correctly, then Im doing something very similar where a workflow basically controls the lifecycle & notifications of a service. I havent seen anything like that with compose yet.

@zach-klippenstein The explicit nature of workflows is awesome. Following the same "steps" when creating a new feature is just amazing for productivity. Have you seen the post about mavericks & compose? After thinking about it all a bunch more, I think Ive also landed on what youve described - and I think their solution resembles the same thing. Keeping state & effects in a workflow would still be benefical I think, but outputs & renders might as well be fully handled by compose?

Edit: The way Elm works its "magic" also reminds me of how one could work with compose+workflows.