[dyarosla]

Is it just me or did the mention of nesting FSMs immediately raise red flags? All I could think of was the rigid hierarchy problem found in OOP- what if your transitions don’t neatly fit in hierarchies? Everything still gets complex.

That said, if HSCs aren’t the solution, what is- specifically to the authors problem of having overly many transitions to ‘home’ states?

[iainmerrick]

If your transitions don’t fit neatly into a hierarchy, you don’t have to use one -- just have a single complex state machine as per the author’s first example.

But I’d propose that a good UI will usually split easily into a hierarchy. I don’t have proof of this, but I’ve worked with both buggy code and confusing UIs caused by multiple inconsistent ways of making essentially the same transition (e.g. in Jira, cards present a slightly different set of controls depending whether you open the URL directly or click on them on a board, and that drives me up the wall). Hierarchical state charts rings true to me as a good approach to fixing this.

[_pmf_]

> All I could think of was the rigid hierarchy problem found in OOP- what if your transitions don’t neatly fit in hierarchies

Yes, HSMs are very rigid. It's one of the few downsides (which I admit as a Harel state chart fanboy)[0]. However, the particular problem you address can be handled by cross-hierarchy events, i.e. one state emits an event, and some other state elsewhere handles it. Plus, of course, not everything is nested; you have orthogonal regions, too.

[0] One interpretation of this rigidity is that it represents the requirements faithfully and compact (YAGNI), so you don't have a level of abstraction that could be used to soften the blows of further requirement changes.

[dyarosla]

Could you link to some examples of events in HSCs/FSMs?