But I’m only implementing my machine in one language, why would this be useful? When do I need the same machine in multiple environments? Or are you referring to things like tooling for visualization etc?
It could be useful in a number of scenarios. For instance you may want to resolve state between a front-end and a back-end, so the ability to make transitions on both could be very useful.
As @CitizenKane pointed out, reusing statcharts between backend and frontend is a growingly popular use case.
Another benefit is you could use any visual tool (preferably web-based with collaborative capabilities so that all stackholders could work togehter) for state modeling to encapsulate business logics completely in statechart then export SCXML to any language you might be using.
I recently discovered state charts via xstate in JS/React. A truly empowering experience. I was able to resolve spaghetti code that accounted for 75% of business logic (not all bad paths handled, or good ones either really) and “worked” 90% of the time (certain transitions in certain states not implemented) into a state machine that accounts for all cases and actually works. Without the state machine, complexity seemed to scale exponentially. With the state machine, complexity scales linearly.
Since then I’ve thought I’m not sure how I could adopt a UI system without a state charts implementation. Most user interactions aren’t that complicated, but some can be, and really do need to be resolved into state machines unless you are an expert spaghetti developer.
So, very glad to see this and hope to see more and more implementations.
Wanted to add some more kind words about XState. It's a key component of a project I'm working on now with some pretty atypical requirements relative to most web projects.
It's been a lifesaver in that regard, and I think we would be a bit sunk without it.
Thank you very much for working on XState, it's a real game changer. Always enjoy your Twitter posts about state machines. Keep up the good work, just realised XState has a Github sponsor button, count me in soon.
State charts (as a specialisation of state machines) are a really underappreciated tool. Fits in with the modern thinking on immutability: you can't really work without state, but you should herd it into clearly defined locations where you can keep an eye on it.
This reminds me of (now from IBM) rational rhapsody from i-logix. Great tool back in 2004 for embedded development and c++ state charts. Also a nice c++ framework, oxf and Omreactive, almost revolutionary for that time. Still being maintained by IBM nowadays but on life support as far as I know.
14 comments
[ 3.0 ms ] story [ 38.7 ms ] threadAnother benefit is you could use any visual tool (preferably web-based with collaborative capabilities so that all stackholders could work togehter) for state modeling to encapsulate business logics completely in statechart then export SCXML to any language you might be using.
In the next version of XState, it will be able to consume and produce SCXML documents as part of its public API.
Another notable library that works with SCXML directly is SCION: http://scion.scxml.io/
Since then I’ve thought I’m not sure how I could adopt a UI system without a state charts implementation. Most user interactions aren’t that complicated, but some can be, and really do need to be resolved into state machines unless you are an expert spaghetti developer.
So, very glad to see this and hope to see more and more implementations.
It's been a lifesaver in that regard, and I think we would be a bit sunk without it.