[RFC] Detect if an event will change the state.

[ChrisShank]

It's quite common to want to know if will the state change if I send a given event? This is useful for when you want to generate a command palette of all of the possible commands a user can do for the given state they are it or for reusing guard logic to disable parts of a UI.

David provided a POC of small helper function that can be added to core to help with this. If we can clarify the name of this helper function it should be really easy to add and test.

canDoEvent = machine.transition(state, event).changed;

Prior art:
@VanTanev's useIsXStateTransitionAvailable

[ChrisShank]

It might also be work adding another helper function that suggested to generate a command palette of events. David outlines what the helper function would look like:

1. state.nextEvents
2. Figure out schema for each event (if applicable)
3. Do canDoEvent trick above
4. Iterate through events that will change state and generate buttons

[davidkpiano]

A related thought I had was that the State object could contain a reference to the machine; no reason why this shouldn't be allowed, as state.configuration already contains the StateNodes that comprise the state.

That means we can provide a helper function: willChange(state, { type: 'someEvent' })

[Andarist]

It would be good to list responsibilities of all core classes etc. We could also differentiate between State, SerializedState, and stuff like that. If we add a machine to the state then it's becoming less obvious what should be kept as a serialized state, potentially saved in a database or something, what can be used as rehydrated state etc. Having a clear pipeline for use cases like this would be a great addition to the docs as well.

[davidkpiano]

For sure. The serialized state should not include the machine.

[ChrisShank]

Regarding you example, i just had a thought where the event payload is necessary to determine if an event changes the state. It seems less common, but does that affect anything?

[steveruizok]

I have a helper named can in state designer that does this and it's very useful, especially for disabling parts of the UI based on an event's payload rather than the active state nodes. (It helps avoid having to model certain minor states).

<button 
  disabled={!state.can("ADDED_ITEMS", count)} 
  onClick={() => state.send("ADDED_ITEMS", count)}
>
  Add {count} items
</button>

The logic is:

• Given the provided event name, the state can handle the event in one or more of its active states
• AND at least one of those active states' handler(s) includes either an action or transition
• AND, given the current context and provided payload, that at least one of those handlers would pass its conditions (guards)

The assumption there is that any action or transition would cause the state to update. I don't execute the action in order to validate that the action actually changed anything.

Note that I broke this handler for certain cases when I added nested logic (ie if a handler would not pass its conditions then can would return false even if the handler had an else handler that would cause a transition to occur).

[davidkpiano]

I like state.can(...); I think it's useful enough to add directly to the State object 🤔

[ChrisShank]

Implemented in #2546