XState – State machines for state management in JavaScript

Thank you for the kind words! I somewhat agree that it is complicated and overly engineered for many applications that don't need all of the statechart features, and that it has a sizable learning curve.

I plan on greatly simplifying it for the next major version, mostly to be more idiomatic and flexible without sacrificing the state machine principles.

Well it mostly can be a static config - although some stuff like inputs can’t be passed in during initiation of the machine (which you can easily do yourself), but imho I also think should just work like with most other parts of the config (guards, actions etc.) One advantage of it being a json format is that you can validate/transform and pass it around with all tool available in this space and that it can easily be understood, written, extended and used everywhere (to a point) where you have a json parser. Also, i wanted to learn rust to write wasm stuff - and my idea fir learning project was a parser for Xstate to create a kind of abstract program … well didn’t get to it - but could see usefulness to having a easily portable standard to describe and mock a program between languages

We have a very complex app with many states for each page. A good example is a liveness detection page where we need to check the user’s face position and inform them on how to move it. Formalizing the acceptable state and state transitions is a game changer.

Well i feel the abstraction itself doesn’t really hinder… what hinders an i realized costs me lots of time is laying out a good looking machine-layout… the auto-layout for machine introspection still is terrible and currently can’t be used with the layouts in the editors. Also I often end up to having copy the machine json back and forth and this usually requires tweeting as Machine inputs still can’t be mapped using strings and I often end up missing some and then wonder why stuff isn’t working as now errors are automatically caught in the machine. What I really like is that I can visualize my programs and clearly communicate a system using the graphs and delegate the parts that have to filled in. I think it’s also great for documentation and making sure a program is built in a nicely testable way and state is only updated at the appropriate times and places (you need to use an assign action). Model-based testing is also a nice feature… as are the ability to restore machine states at later times using saved state or replaying events. Although I never have done it I enjoy the thought of just taking my machine and put it into another web-fronted and only rebuild the UI by binding the view to state/context and interactions to basic dom events. All in all I think it can have big benefits of having a UML like visualization of your program that can be introspected live at run-time and isn’t immediately outdated because nobody bothers to keep it up to date after a code update (because it is the code). But it surly is a bit of a learning curve… but I encourage you to just try it out beginning with very small machines and build from there. Many of my problems come from just trying to build a giant machine system with many communicating actors from the start. Which totally isn’t needed to assess its features/drawbacks