It's an insanely overcomplicated and over-engineered piece to a point of being unusable.
Having said that I have to point out three important things:
1. Its author is very helpful and communicating over twitter/etc. He has written a nice article on how to implement xstate-like machine in just a few lines of code [1] and he argues this solution is fine for the majority of use cases.
2. He has created visual designer for xstate machines[2] and it has been a godsend for some of my complicated state machines (think transaction processing).
3. IMO the sane way of using xstate is to completely ignore it's data managing capabilities (inputs and outputs) and instead instantiate your own object with all the data you need to pass to/from the state machine. Even in typescript.
In overall, despite my hate towards overengineered things, xstate + stately has been incredibly useful to me on a number of projects and I am a fan of it.
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
It's an insanely overcomplicated and over-engineered piece to a point of being unusable.
Having said that I have to point out three important things:
1. Its author is very helpful and communicating over twitter/etc. He has written a nice article on how to implement xstate-like machine in just a few lines of code [1] and he argues this solution is fine for the majority of use cases.
2. He has created visual designer for xstate machines[2] and it has been a godsend for some of my complicated state machines (think transaction processing).
3. IMO the sane way of using xstate is to completely ignore it's data managing capabilities (inputs and outputs) and instead instantiate your own object with all the data you need to pass to/from the state machine. Even in typescript.
In overall, despite my hate towards overengineered things, xstate + stately has been incredibly useful to me on a number of projects and I am a fan of it.
[1] https://dev.to/davidkpiano/you-don-t-need-a-library-for-stat... [2] https://stately.ai/
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.
I'm looking forward to it and ready to beta test immediately!
PS: while we're at it, could you please take a look at #248 @ GitHub. Seems like this issue's export to linear failed when I have opened it.
You and your team are real MVPs.
I'm all for declarative DSL, just not sure why it has to pretend to be a static config. A functional API can look much cleaner.
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
I always want to use this lib and end up just doing small simple solutions.
Does anyone have case examples of when this abstraction helps vs hinders
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