Clicking GO multiple times and wait for 2 secs - doesn't advance

[iangregsondev]

Hi,

Tried this

https://xstate-catalogue.com/machines/debounce

in chrome, clicking the yellow GO event multiple times - then it goes to debouncing.... if I stop pressing the GO then it doesn't seem to advance.

Maybe I am doing it wrong ?

[mattpocock]

Interesting, can't seem to repeat this. What device/browser are you on?

[bemayr]

Just dug into this and the problem is tricky, although very interesting.
It makes a difference which GO button you click, because the events that are sent are different ones.

If you click one of the yellow GO buttons in the machine description then it works, because @mattpocock correctly defined the event (with the needed payload) in here: https://github.com/mattpocock/xstate-catalogue/blob/master/lib/machines/debounce.mdx#pressing-go

When the machine is in idle state and you send event: { type: "GO", action={() => alert('Action fired!') } to it it will store this action in the context and execute it after the 2000ms debounce time.
The problem now is that if you only send event: { type: "GO" } to the machine (which happens if you click ON in the visualizer or ON in the left sidebar then action is undefined and the machine crashes during performAction.
You can add the necessary payload to the event in the visualizer under the Events tab and sending the event there.

So afaik this leads to two questions:

1. Should we rewrite the machine's performAction action to correctly handle an undefined event payload? (@mattpocock)
2. And how could the <SideBar> component in [id].tsx L338-L346 know about event payloads? I think if I remember correctly @davidkpiano you told me about your idea of a dialog in the visualizer/simulator for this?) Or @mattpocock do you already have an idea on how to implement this in the interactive documentation? I am dreaming of a UI for this that derives the form based on the event payload type. 💭

btw. @mattpocock, really nice modelling of sending an event with a payload via mdx! 🤓

[bemayr]

A really simple but working rewrite is

performAction: (context) => {
  return context.action && context.action();
},

though IMO this is really bad, because it hides the fact that no action was executed!

What would be the expected behavior if no action was defined?

And one more question: The visualizer does not show the action in the context. Is this expected behavior, because it is a function @davidkpiano?

[mattpocock]

@bemayr

Aha! It's one of these. OK, my plan here is to have something like this in the MDX file:

export const meta = {
  defaultEvents: {
    GO: {
      action: () => {},
    },
  },
};

This means that the events on the sidebar will have something to inherit so they won't be firing just a dumb event.

Thanks for the digging @bemayr!

[mattpocock]

@iangregsondev @bemayr Does this work for you?

https://xstate-catalogue-git-mattpocock-issue6-mattpocock.vercel.app

[bemayr]

Nice idea! I like the defaultEvents implementation and now the Sidebar works as expected! 👏

The only problem left over now is that clicking on an event in the visualizer does not work as expected, and I am afraid that this will confuse/frighten people. :/

[mattpocock]

Yeah, that's interesting - that feels like something that could be merged into @xstate/inspect. I.e. an option to pass inspect() a bunch of default event payloads which it can reference when sending events. I'll merge the PR and raise an issue there.

[bemayr]

Perfect, thank you!