derkork
commented
2 months ago The current implementation is according to the specification (https://statecharts.dev/glossary/history-state.html) and all state chart implementation that I have seen work this way. Interestingly, it is nowhere defined what should happen if you enter a history state without leaving the surrounding compound state, so technically this behaviour is undefined. I'm not quite sure what a useful behaviour would be in this case, especially if the compound state contains additional compound states. E.g. let's assume we have this:
We start in B then go to C then go to A1 which transitions to A2 which transitions to the History State. Where do we end up now? In A1 or in C ? This probably depends on whether the history state is deep or not. But for the history state to be able to go back to A1 it would need to continuously track all sub-state changes (and their substate changes) which will lead into quite the rabbit hole. I guess that's the reason why the spec conveniently leaves this point out.
tkuebler
I've discovered that for the state to be saved you have to exit the compound state - this is counter intuitive to me, although now that I know that I can design around it. This is more of a question/suggestion than an issue.
My original state chart that does not save state on atomic task exit but is simpler and more intuitive IMO but does not work.
This works, but is more complex.
I'm ok with the way it works now that I have figured it out, but it seems also keeping track of state inside a compound state would lead to simpler state charts in some cases. You have to really read the documentation carefully to catch that you have to leave the state and return for the history to work.