Allow non-string EventTypes/ActionTypes

[JonasKruckenberg]

With large state machines it is common to have many event and action types. Currently all events/actions must be identified by strings, which tends to cause those strings to spread all over a codebase.
As string identifiers can’t be minified xstate state machine code ends up being a real size concern.

It would be nice to allow any type (maybe only value equality types) as identifiers, so one could use typescript number enums to identify events/actions.

This would also help tremendously with obfuscation in security oriented js code.

[Andarist]

Using other stuff than strings poses some technical challenges for us. I recognize the bundlesize argument and agree that it would be nice to do something about it but there are no current plans to remedy this anyhow. I think it's important to make other foundational pieces stellar before thinking about such optimizations. The security argument doesn't really strike me as an important one though because, in my opinion, security by obfuscation can only give you a false sense of security. Obfuscation doesn't raise security, it only raises the entry barrier for a potential reader. I've read a fair amount of the obfuscated code myself and I can assure you that it is very much doable and if somebody gets super determined to read your public code (where any code living in the frontend can be considered "public") then they might succeed in doing that.

[JonasKruckenberg]

Using other stuff than strings poses some technical challenges for us. I recognize the bundlesize argument and agree that it would be nice to do something about it but there are no current plans to remedy this anyhow.

Thank you for the clarification, we all need to prioritize, so I'm happy that I at least raised awareness about this.

The security argument doesn't really strike me as an important one though because, in my opinion, security by obfuscation can only give you a fall sense of security.

Don't get me wrong here, obfuscation alone almost never works. But it can be used as one layer of many and especially with xstate apps, where the state machine encapsulates the entirety of an apps logic obfuscation would help a lot in slowing down attackers.

I discussed possible workarounds with my team yesterday and this is what we came up with:

import { createMachine } from 'xstate';

const STATE_PENDING = 'pending'
const STATE_RESOLVED = 'resolved'
const STATE_REJECTED = 'rejected'

const EVENT_RESOLVE = 'RESOLVE'
const EVENT_REJECT = 'REJECT'

const promiseMachine = createMachine({
  id: 'promise',
  initial: STATE_PENDING,
  states: {
   [STATE_PENDING]: {
      on: {
        [EVENT_RESOLVE]: { target: STATE_RESOLVED },
        [EVENT_REJECT]: { target: STATE_REJECTED }
      }
    },
    [STATE_RESOLVED]: {
      type: 'final'
    },
    [STATE_REJECTED]: {
      type: 'final'
    }
  }
});

It forces one to use the constants to interact with the state machine, ensuring no string literals are duplicated and the odds a machine declaration survives obfuscation are high.