Closed Glutoblop closed 10 months ago
What you describe is called a "Condition State" (https://statecharts.dev/glossary/condition-state.html). The idea is that you enter one state and then on entering you immediately switch to the next state based on some guards. And yes this is very much possible to do with the current implementation.
You have a variation of that, in that you want to evaluate these on a certain event, rather than when the state is entered. Using an empty event is intended to signal transitions that should automatically run when the state is entered, so you probably don't want to use an empty event for this unless you want these transitions to run whenever the state is entered. But you can really use any other event name. E.g. you could use a generic event name like "tick" and then let everything react to this event.
This way it would require no workarounds at all, just using the built-in functionality in a specific way.
Using the tick
event instead of blank is a good shout, it means I don't have to disable transition on enter to fix a recursive bug I was having with my work around. Thanks!
If you never use the
event
field in transitions and always leave it blank, you can instead just use expression guards on your transitions and use these as conditional statements for the transitions.The only additional requirement for this work around is to emit a blank event [duration of your choosing] from a managing object and it works very cleanly to allow complex conditions to work in your transitions.
Is there any reason you would be against having this as a fully built in supported feature instead of work arounds? Or if this was the intention then it works great!