fulcro

roklenarcic 2026-03-16T07:36:33.783689Z

I was trying to do a generic debouncer. Initially made a state chart that gets invoked as a child chart and it captures events sent to it, then replays the last event back to parent after a delay if no events received. Then the parent would control what event it forwards there. It didn’t work because I was trying to make a transition in that debouncer chart with :event :* to handle any event and that didn’t work. Making a transition with no event just creates a loop. Not sure how to swing this one.

michaelwhitford 2026-03-16T07:42:05.329279Z

It sounds like a problem similar to one I ran into where targetless transitions in an invoked sub chart would not cause the done.invoke event to fire. To get around that I made a :progress event that the chart could send to itself to progress to the next state, instead of using targetless transitions. Not sure if that would apply to your problem but your description made me think of this sub-chart I had to make look a little strange to get the behavior I wanted.

tony.kay 2026-03-16T22:14:27.916129Z

So, the option that comes to mind for me is to put a debouncer on your sending (or implement it into the event queue)…e.g. don’t model the concern in the statechart itself.

tony.kay 2026-03-16T22:16:16.971309Z

Wrapping your send function in a debounce is best if you’re worried about user events (double clicking on Pay)…that said, the chart itself can be structured so that repeat events are just ignored…e.g. put the transition for the “pay” in a state that is waiting for the user to click that. They click that and you move to a state where the pay transition isn’t available. The extra “pay” event is just ignored as a matter of course.

tony.kay 2026-03-16T22:17:11.839089Z

I would say using the structure to naturally “ignore” repeat events would be the most idiomatic, but I can also see a case for trying to limit accidental repeats, but in that case I’d lean towards an “external” debounce, not a trick in the chart.