Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: