I do some work in ocaml where state machines are popular I think because of how cleanly they map onto the language constructs. One common approach is the elm-is

I do some work in ocaml where state machines are popular I think because of how cleanly they map onto the language constructs. One common approach is the elm-ish move of having the machine fn return a pair of (new state, action). Then you have an intermediate fn run the side effects, but you can implement that somewhere else and mostly pretend it's not there. React reducers are kind of like this too. When doing this though like you said you always either find there are more states than you initially thought, or you end up having pseudostates only for their effects. I pretty much only reach for state machines when I know the inputs will never change and I'll never have to modify the implementation. Even in a language almost perfectly suited for them they are hard to understand once they're doing all the edge cases and side effects and edge cases of the side effects and error handling etc etc.