Can I stop the execution of an action without continuing the logic?

[melishev]

For example, I have a code like this:

states: {
  IDLE: {
    on: {
      MAKE_SOMETHING: {
        actions: () => {
          const user = context.users.find((user) => user.name === 'xstate')
          if (!user) {
            throw new Error('user not exist')
          }
          // ...
        }
      }
    }
  }
}

The code above is perfect for me, since I already have a codebase and am porting the code to xstate. I have complex calculations in actions that will either execute or not, let's say it's random.

But, in the case of “throw new Error()”, I will get a stopped actor that is no longer running. And that's terrible!

Ok, I've read your documentation and realized that you want actors in general to prevent such situations, that it would be solved at guard level, but:

1. If I allocate code in guard, in my case this guard will be used only once, in this place.
2. If I allocate code in guard, I still need to leave the code in actions, i.e. to make calculations twice as long

states: {
  IDLE: {
    on: {
      MAKE_SOMETHING: {
        guards: ({ context }) => !!context.users.find((user) => user.name === 'xstate')
        actions: ({ context }) => {
          const user = context.users.find((user) => user.name === 'xstate')!
          // ...
          // find() isn't as overhead in terms of costs, but that's just for the sake of example
        }
      }
    }
  }
}

The 2nd point is especially important, and it's quite critical, especially since my case study involves a server application, not a client application.

Question: is there anything else I may have missed by studying your library that will help me with my situation? Thank you

[melishev]

@Andarist @davidkpiano @mattpocock
Also, in any case, I think that the philosophy of handling erroneous states in the xstate documentation should be described more explicitly, perhaps in a separate section

[melishev]

@Andarist @davidkpiano
A solution to my problem would be enqueueActions, for example:

exampleAction: enqueueActions(({ context, enqueue, check }) => {
  const user = context.users.find((user) => user.name === 'xstate')
  if (check({ type: 'exampleGuard', params: { user } })) {
    // ...
  }
})
// ...
states: {
  IDLE: {
    on: {
      MAKE_SOMETHING: {
        actions: 'exampleAction' // stop transition to target if check inside is false
        target: 'nextstate'
      }
    }
  }
}

On the one hand, it would be logical that since we use “check” with the defender, the further logic of the state transition would stop.

But then this would mean that we now have actions that can stop the transition as well as protectors.

What do you think?

[davidkpiano]

A current alternative is to conditionally raise(…) an event based on a condition.

But in the future, we want to have a simpler API that lets you handle transitions as functions:

// TENTATIVE FUTURE API
on: {
  MAKE_SOMETHING: ({ context, enqueue }) => {
    const user = context.users.find((user) => user.name === 'xstate');
    if (!user) {
      return; // void/undefined = no transition
    }
    
    enqueue(someAction); // still "pure", doesn't execute yet
    return {
      target: 'nextState',
      context: {/* change context */}
    };
  }
}

[melishev]

Your suggestion for a future working mechanism, looks really impressive and will help close more cases. Is there somewhere to track the plans for the new version?