Refer to xstate to improve useStateMachine

[junerver]

The way to create a state machine in xstate may be very useful for reference, for example:

const textMachine = createMachine({
  context: {
    committedValue: '',
    value: '',
  },
  initial: 'reading',
  states: {
    reading: {
      on: {
        'text.edit': { target: 'editing' },
      },
    },
    editing: {
      on: {
        'text.change': {
          actions: assign({
            value: ({ event }) => event.value,
          }),
        },
        'text.commit': {
          actions: assign({
            committedValue: ({ context }) => context.value,
          }),
          target: 'reading',
        },
        'text.cancel': {
          actions: assign({
            value: ({ context }) => context.committedValue,
          }),
          target: 'reading',
        },
      },
    },
  },
});

We can refer to it to implement this DSL. Using the features of Kotlin, we can do the following:

    val machineGraph = createMachine<LoadingState, LoadingEvent> {
        initial(LoadingState.IDLE)

        state(LoadingState.IDLE) {
            on(LoadingEvent.START) { target(LoadingState.LOADING) }
        }

        states {
            LoadingState.LOADING {
                // Loading can succeed or fail
                on(LoadingEvent.SUCCESS) { target(LoadingState.SUCCESS) }
                on(LoadingEvent.ERROR) { target(LoadingState.ERROR) }
            }
            LoadingState.SUCCESS {
                // Success state can restart or fail
                on(LoadingEvent.START) { target(LoadingState.LOADING) }
                on(LoadingEvent.ERROR) { target(LoadingState.ERROR) }
            }
            LoadingState.ERROR {
                // Error state can retry
                on(LoadingEvent.RETRY) { target(LoadingState.LOADING) }
            }
        }
    }

[AKAAE86]

Great! I think this solution is more intuitive and readable, especially the overridden operator function. But it seems that the current solution actually allows users to change the target according to the business logic within the event scope. I think this is the key point of keeping the event scope separate because if we just want to statically describe the graph state, we might not need an extra layer. Both of these two approaches are okay for me.

[junerver]

I also thought about using Event target State action {} as a continuous infix function call method, but it seems that it cannot prevent users from describing dynamic graph states.

[AKAAE86]

And I also have a idea about adding a side effect handler to allow user to execute some task when receiving a specific event.

[junerver]

I just implemented action, but it can't drive context. You can take a look at the code, maybe you have a better way to handle it.

[AKAAE86]

There is a well - known solution for state machine in kotlin. We can also refer to it. Here is the link below.
https://github.com/Tinder/StateMachine

[AKAAE86]

I will consider how to implement a context driven approach which is similar to xstate when I have time.If I make any progress or I have done a draft pr I will discuss with you

[junerver]

Thank you for your time

[junerver]

Hi, I have preliminarily completed the implementation of the two DSL functions action and context. You can review these codes when you have time.

696a008

[AKAAE86]

LGTM