1) Your user interface probably has more edge cases than you or your designer anticipated, and IME the most efficient, understandable way to deal with these is in as-simple-as-possible plain-old-code if/else business logic. The further away you keep code like that from anything "frameworky" the less likely you are to regret it as tech debt.
2) Many of your state transitions probably share similar helper logic. So you want to break that stuff out into its own non-state-based organization anyway to avoid copypasta, and at that point, similar to the above, representing different use cases as linear code as much as possible is a low-cognitive-overhead way to organize your biz logic. That is to say: I think your "states" should be big and chunky - occasionally one feature's flow will transition you into a different feature, but whenever I've tried to push that model down to the individual screens and buttons level, it's caused self-induced pain.
If I had to reduce it to a soundbite, I'd say: your business logic is likely to be inherently complex. Don't intermix that complexity with the technical complexity of your application framework if you can at all avoid it.
(Where this KISS approach goes wrong in practice is you don't have enough team discipline about organizing your biz logic code, or you try to share the wrong things/too early, and some biz logic ends up in every layer of the UI, and you get lots of big pull requests touching lots of files with hot spot files frequently having merge conflicts.)
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.
I'm confused because statecharts don't describe business logic - you might be confusing them with flowcharts which are inherently very different: there's no concept of state in flowcharts.
> the most efficient, understandable way to deal with these is in as-simple-as-possible plain-old-code if/else business logic. The further away you keep code like that from anything "frameworky" the less likely you are to regret it as tech debt.
A statechart is simply a JSON structure. You still have to write the code for the figuring out what to do given the current state, and also code for triggering events. So it's still up to you to keep them away from anything frameworky.
> representing different use cases as linear code as much as possible is a low-cognitive-overhead way to organize your biz logic.
Again, you'd still write linear code with statechart.
> your business logic is likely to be inherently complex. Don't intermix that complexity with the technical complexity of your application framework if you can at all avoid it.
With statecharts your business logic is anywhere you want it to be. Statecharts add the idea of limiting you of calling only procedures that are allowed by the current state; meaning that if you are in state "Submitting form" and you call a `goToHomePage()` transition, nothing will happen if there's no such outgoing arrow.
This concept of "changing state only if the current state allows it" is quite powerful especially in the construction of UIs.
1) Your user interface probably has more edge cases than you or your designer anticipated, and IME the most efficient, understandable way to deal with these is in as-simple-as-possible plain-old-code if/else business logic. The further away you keep code like that from anything "frameworky" the less likely you are to regret it as tech debt.
2) Many of your state transitions probably share similar helper logic. So you want to break that stuff out into its own non-state-based organization anyway to avoid copypasta, and at that point, similar to the above, representing different use cases as linear code as much as possible is a low-cognitive-overhead way to organize your biz logic. That is to say: I think your "states" should be big and chunky - occasionally one feature's flow will transition you into a different feature, but whenever I've tried to push that model down to the individual screens and buttons level, it's caused self-induced pain.
If I had to reduce it to a soundbite, I'd say: your business logic is likely to be inherently complex. Don't intermix that complexity with the technical complexity of your application framework if you can at all avoid it.
(Where this KISS approach goes wrong in practice is you don't have enough team discipline about organizing your biz logic code, or you try to share the wrong things/too early, and some biz logic ends up in every layer of the UI, and you get lots of big pull requests touching lots of files with hot spot files frequently having merge conflicts.)