workflow-kotlin
workflow-kotlin copied to clipboard
square
Feature Request: RenderingWorkflow
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>()
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.
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.
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?
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 😁
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.
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>?
Seems to me that we've been through a few loops of introducing a "clarifying" alias like this, then regretting it and inlining.