Xstate: Combine Actions and Activities

[RainerAtSpirit]

Bug or feature request?

Feature request Updated

Description:

Just want to capture information from a conversation at React Finland. It looks like the only difference between Actions and Activities is that the later can be canceled. Activities in itself have no real meaning in SCXML so we might be able to simplify the API by removing Activities altogether and provide the ability for actions to be called with or without cancellation.

(Bug) Expected result:

(Bug) Actual result:

(Bug) Potential fix:

Required! If you found a bug and can consistently reproduce it, please take a minute to think about what the potential fix might be.
Even if the fix is incorrect, this can help diagnose and find the solution to the issue as quickly as possible.

I also strongly encourage you to create a pull request if you are confident in the potential fix.

(Feature) Potential implementation:

Required! If you would like to see a feature or enhancement make its way to xstate, please describe:

• What the API would look like

Remove Activities replace with Action plus optional cancellation

• If this is a breaking change

This would be a breaking change.

• If this is part of the existing SCXML specification

Link to reproduction or proof-of-concept:

You can use CodePen or Code Sandbox to create a reproduction/POC.

[coodoo]

I was pondering over this last week too, but instead I would vote for replacing activities with services (promise, callback, sub-machine), for that the latter is like a superset than the former.

By doing so you could have long-running side-effects continuously going on, and also have the capability to communicate with the parent machine, which IMO is way more powerful than activities.

My wild guess that activities was put in there is because it was mentioned in the original statecharts paper?

[RainerAtSpirit]

@coodoo Interesting idea, but I'm afraid that would go a little bit too far. One of the goals of xstate accoding to the docs is to

Aheres to the SCXML specifications.

Both Actions and Invoking services are part of the specs, while activities are not. Goal of this feature request is be to have a smaller API and less confusion for beginners (at least I was confused of the differences of the two) and still stick with the specs.

[coodoo]

be able to simplify the API by removing Activities altogether and provide the ability for actions to be called with or without cancellation.

After having a second read of what you proposed I actually think it made a lot of sense 👍👍

[davidkpiano]

There is also the difference that activities are meant to run for the duration of the state (in the original paper, they are labeled _"throughout"_), whereas actions can be executed at any time. Activities cannot start at arbitrary times; only when a state is entered.

For example, if we took this proposal, this would be ambiguous:

foo: {
  onExit: (ctx, e) => {
    // start activity
    return () => {
      // stop activity, but... when does this get called?
      // immediately? when the next state is exited?
    }
  }
}

[RainerAtSpirit]

@davidkpiano Thanks for the additional information. Just curious I glanced through the SCXML specs and couldn't find activities there at all. Into what did they transcend?
On thought how to address the concerns in the example above: we might implement an "activity" as an overload to the onEntry action that allows cancellation as a second argument.

[davidkpiano]

This will be addressed separately, in combining activities with invoked services instead of actions.