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