[Discussion] About the onChange site effect

[phamnhuvu-dev]

In the state chart spec, the State only has onEntry and onExit
https://www.w3.org/TR/scxml/#onentry
Why does this package have onChange?

[pierremrtn]

This package is kinda experimental, it didn't follow any specs.
I was considering discarding it / having a big refactor since I'm not happy with the API design.
I think it would be interesting to study some state machine standards to do a rework.
Can you please elaborate on this?

• Do you think is an anti-pattern to have onChange?
• Is this spec the most pertinent to follow, are you aware of other ones?

[HighLiuk]

@Pierre2tm do you know about XState on the TypeScript ecosystem?
It shares most features with fsm2 since it's based on the SCXML standard - the same pointed out by @phamnhuvu-dev.

More on XState if you're curious

If you're interested, I recommend this brief intro > https://www.youtube.com/watch?v=2eurRx-tR-I

IMHO the most valuable feature of XState is its visualizer, which is a free online tool and also has a VSCode extension (this one I would recommend).

I guess it should not be too hard to use code_builder to read the JSON config of XState and generate boilerplate for fsm2.
This "recycles" the (extremely developer friendly) experience of using the visual editor of XState on the IDE to bring that into dart.

Side technical note: XState config is not JSON but JS since it may have some business logic on it, but may not.

[pierremrtn]

@HighLiuk, thank you for pointing this out. I wasn't aware of this XState tool, but it looks gorgeous, and I would love to have an integration with Dart.

I've been working on this package recently: https://github.com/Pierre2tm/state_machine_bloc. It's basically the same code as this state machine but decoupled from Bloc and aligning with the SCXML standard.

I plan to refactor this project to use reactive_state_machine under the hood. It should be relatively straightforward to do so and would make adoption of this package less risky. It should let users migrate to other state machine packages afterward without having to rewrite everything.

I think this would also play nicely with the recent addition of Dart DevTool extension. This would be a lot of work, but having such a powerful visual editor would definitely bring this package to the next level. I'll experiment with XState myself to get familiar with it, but I'm convinced that such visual tools are the way to go, no matter if we use XState or something else.

I would be happy to receive any help from your side, feedback, or even pull requests.

I've created related issues for this package and the reactive_state_machine package so we can continue the discussion there:
migration to reactive_state_machine
xtate integration
dev tool visualizer