State Machine is just state machine. I don't understand the immediate association you implied with over-engineering.
It is essential for developing complex component, where to accomplish a single transaction requires a series of actions that is inseparable from each other, e.g. creating a viewable configuration object that has internal dependency among itself, or complex annotation tools.
To keep you sanity to handle the dependencies, and failure case, you need a state machine, period, or you invented your own without knowing, or your code is just too broken to be fixed.
Sure; but with redux the state machine is site-wide, and needs to be modelled with actions and reducers.
With svelte, a state machine is just a variable or two, that you can just assign to. Rendering (and programmatic hooks) react to those variables changing without any effort on your part. And those variables can be local or shared between components, just like any other piece of code.
It’s still, obviously a state machine - but because you can implement it with half as much code, you’ll have half as many bugs and you’ll finish faster. The outcome is the same, but the expression is better in my opinion. (There is something to be said for having all your state in one place - but you can just organise your svelte code like that if you really want to.)
The transitions between states in the Svelte example are also completely uncontrolled and there is no guaranteed flow from state A => B => C. That is completely fine in many cases, most cases I would say. The problem is when you encounter a scenario where predetermined flow and guaranteed state transitions matter and you're trying to cobble it together. Robot and XState aren't React libraries, they're just Javascript libraries. Not every solution needs them but to dismiss the idea as overengineering or React specific because you can assign to variables in Svelte is missing the point.
Sure; but you can handle that as we do in other programs: if it makes sense to do so, make a single method responsible for modifying a state variable and call that instead of assigning directly. And that can manage side effects. Alternately, trigger other changes off the state variable changing using svelte’s reactive code blocks. This style of programming can scale up and down in complexity like any other code you write, and you can scope it and refactor it along with everything else.
What is your argument here? That we already work with state machines implicitly in UI code so there's no point in making it explicit with a library? That Svelte's reactive mechanics are so good that it doesn't make sense to use an external library even if it is specialized for modelling things as a state machine?
Because I agree with you that Svelte is great and reactive programming is powerful but if you had a problem that looked and acted like a state machine, why you wouldn't just use a state machine? And if someone had a library ready to go that managed it for you, so much the better.
Yes, and at a certain level of complexity you might decide to reify the state transitions in your centralized svelte state into a concrete state machine. Perhaps you will use Robot to do that!
React too can be used without a state library or a global reducer but they are tools you reach for when complexity strikes.
It seems unlikely that svelte’s coding model is a silver bullet that eliminates the need to use more advanced coding strategies to handle the essential complexity of larger state fuel applications.
It is essential for developing complex component, where to accomplish a single transaction requires a series of actions that is inseparable from each other, e.g. creating a viewable configuration object that has internal dependency among itself, or complex annotation tools.
To keep you sanity to handle the dependencies, and failure case, you need a state machine, period, or you invented your own without knowing, or your code is just too broken to be fixed.