If you think that's the simplest you could get, more power to you. I personally think your example is convoluted for such a simple example, but that's just me.
However, I should point out something that is not actually trivial about your code, by proposing a refactor: your FSM adequately models a car lock button interface, but not the lock itself. If we are modeling the lock, you have two invalid transitions...because it is impossible to lock an already-locked lock, and it is impossible to unlock an already-unlocked lock.
Classes actually shine quite well here.
class On {
constructor(){
console.log('turned on')
}
turnOff(){
console.log('turning off...')
return new Off();
}
}
class Off {
constructor(){
console.log('turned off')
}
turnOn(){
console.log('turning on...')
return new On();
}
}
const toggle = new On();
toggle.turnOff().turnOn().turnOff().turnOff()
// ^ cool, ^ cool, ^ cool. ^ oh shit, typescript really doesn't want to let me do this.
Classes can model your original scenario quite easily (just add a `turnOn()` method to `On` and `turnOff()` to `Off`, but redux can't model my scenario (at least not without more boilerplate and lots of guards). More importantly, the available actions are localized...I don't have to create a monolithic state transition table logic...I only have to concern myself with the possible transitions for any given state. This makes it trivial to add new states or new actions, because I will never have to worry about the combinatorial explosion that can happen in a global transition table.