search

square / workflow-kotlin

A Swift and Kotlin library for making composable state machines, and UIs driven by those state machines.
https://square.github.io/workflow
Apache License 2.0
1.03k stars 101 forks source link

Feature Request: RenderingWorkflow #757

Open digitalbuddha opened 4 years ago

digitalbuddha commented 4 years ago

StatelessWorkflow is very nice, I'd love a new workflow which does not have state or output.

proposed implementation:

abstract class RenderingWorkflow<PropsT, RenderingT> :
    StatelessWorkflow<PropsT, Nothing, RenderingT>()
zach-klippenstein commented 4 years ago

What value would having a separate type for this provide, besides eliminating one type parameter in the interface? The only reason that StatelessWorkflow exists is to avoid the boilerplate of requiring implementers to override meaningless initialState and snapshotState methods. In the Swift API, there's no separate type for this, the language allows them to define default implementations for these methods when the State type is Unit. In this case, RenderingWorkflow would have the same render method as a generic StatelessWorkflow with OutputT == Nothing.

digitalbuddha commented 4 years ago

That makes sense as initial motivation for the split. I felt that declaring a needless Nothing parameter is unnecessary and does not show any additional intent. The mental load associated with it can be reduced, initially I did Unit there. I can keep it as a local warpper thanks for considering, have a nice day.

zach-klippenstein commented 4 years ago

That's useful feedback, thanks! We could also potentially do this:

typealias RenderingWorkflow<P, R> = StatelessWorkflow<P, Nothing, R>

I think that would solve the problem as well?

digitalbuddha commented 4 years ago

Yup! After a bit of usage it makes sense why workflow has 4 parameterized types. I imagine a new engineer to be terrified looking at something of that sort. The simpler that the simple case looks the easier my life will be getting adoption 😁

zach-klippenstein commented 4 years ago

Also a good use case.

zach-klippenstein commented 4 years ago

One thing that could be confusing with this is that you also might want to have a state ful workflow that doesn't have any output, so we might also want a StatefulRenderingWorkflow. In general, we tend to avoid over-specializing on this stuff because of the combinatorial explosion with all the type parameters.

rjrjr commented 4 years ago

I'm wary of this. It seems obfuscating to me, and another bit of cognitive load — when I see RenderingWorkflow I have to go find out what it means. Is it really easier to learn / internalize than just StatelessWorkflow<P, Nothing, R>?

rjrjr commented 4 years ago

Seems to me that we've been through a few loops of introducing a "clarifying" alias like this, then regretting it and inlining.