Re:Xstate: State machines and statecharts for the modern web
by fallingmeat on Monday March 27, 2023 @02:27PM
(#35330368)
do you foresee sysml like diagrams in your roadmap? if you could do activity diagrams with swimlanes…dude. that'd be huge.
Re:Xstate: State machines and statecharts for the modern web
by davidkpiano on Monday March 27, 2023 @03:36PM
(#35331274)
Yes! Visualizing how different actors communicate with each other in general is a big goal for us this year. We're going to start with sequence diagrams.
Re:Xstate: State machines and statecharts for the modern web
by nickpeterson on Monday March 27, 2023 @08:47PM
(#35334285)
I know this probably isn’t on the radar, but process trees or pétri nets with token visualization feels doable, any interest in supporting those kinds of tools?
Re:Xstate: State machines and statecharts for the modern web
by tobr on Monday March 27, 2023 @04:20PM
(#35331892)
Hello! I’ve looked at XState a bunch of times but always felt it seemed very involved for what it does. A simple “vanilla” state machine isn’t particularly complicated.
Are you sure you need to bring “even more features”, or rather, what are your thoughts on how feature-rich a state machine library needs to be?
Re:Xstate: State machines and statecharts for the modern web
by julenx on Monday March 27, 2023 @05:12PM
(#35332716)
For vanilla state machines there's also @xstate/fsm. In their docs[1] you have a feature comparison.
Re:Xstate: State machines and statecharts for the modern web
by ar-nelson on Monday March 27, 2023 @05:28PM
(#35332910)
Would you consider supporting Deno? (The npm module can probably be imported as-is in newer Deno versions, but a dedicated module is always nice and likely wouldn't be much work)
Re:Xstate: State machines and statecharts for the modern web
by capableweb on Monday March 27, 2023 @08:24PM
(#35334132)
If it (probably) already works as-is, why not just use it? Why is it nicer with a "dedicated module" if using it from npm is the same? More work is more work, reducing maintainer work is something we should strive towards, rather than adding "just a little bit of work".
Just want to mention that we're very close to releasing XState v5 beta, which brings even more features to the state machines & statecharts you can create, and greatly improves the developer experience, but also makes it more usable as a general-purpose state management library (or orchestration "framework" if you want to consider it that), whether on the frontend or backend.