> allowed different parts of the API to be independent and composable while still ensuring that result types align
I found that states are not really required to know anything about internals of the executed code. All that a policy needs to know if the next state is an error or not, that's all.
I might have simplified the problem too much for my library to be useful in real life applications, but I still hold hope that a
stateFn func(context.Context) stateFn
is expressive enough for implementing the whole functionality.
If I may make another suggestion, I found that for more complicated flows, it is useful to be able to build a graph. I have made a rough approximation of a toold for my project based on parsing the go sources and inferring a state diagram from it. You can check it here: https://git.sr.ht/~mariusor/ssm/tree/master/item/cmd (Apologies for the lack of documentation, my work is much more recent than yours :D)
I found that states are not really required to know anything about internals of the executed code. All that a policy needs to know if the next state is an error or not, that's all.
I might have simplified the problem too much for my library to be useful in real life applications, but I still hold hope that a
stateFn func(context.Context) stateFn
is expressive enough for implementing the whole functionality.
If I may make another suggestion, I found that for more complicated flows, it is useful to be able to build a graph. I have made a rough approximation of a toold for my project based on parsing the go sources and inferring a state diagram from it. You can check it here: https://git.sr.ht/~mariusor/ssm/tree/master/item/cmd (Apologies for the lack of documentation, my work is much more recent than yours :D)