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.
> 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.