ISBN: 0201342782

Found in 1 comment

by davidkpiano

2017-12-03

I think the big misconception here is that statecharts _have_ to be framework-y. They don't, and their biggest benefit (in my opinion) is how they shift the mental model of creating UIs from "bottom-up" to "top-down", so that even if you're not explicitly using finite state machines or statecharts, your UI benefits from better maintainability.

Here's the thing. As developers, we write implicit state machines in our UIs all the time, in the form of boolean flags, or enums if we're feeling disciplined, or peppered if-else statements everywhere. Arguably, most (if not all) UIs can be represented as explicitly classifiable states, and actions that can occur that can transition those states into other states.

So I'd argue that having _some_ sort of declarative formalism for describing your app's states and transitions is much more beneficial than having an ad-hoc way of imperatively changing states, which most of us developers are wont to do, since it's "easier" to implement.

Since statecharts are hierarchical graphs, there's also the possibility for automatically analyzing, optimizing, and generating full integration tests for user flows given a statechart spec.

I agree that trying to use statecharts everywhere is fitting a round peg into a square hole, but thinking about the UI in terms of states, and actions in terms of something that is simply emitted instead of something where application logic is stuffed into, will greatly improve how UIs are developed in the future.