Xstate: Combine activities & invoked services

[Andarist]

Invoked services are kinda a superset for activities - the lifetime of both are bound to state and there is nothing you can do with activities that u can't do with invoked services.

It would be beneficial for users to deprecate activities all together as that would be one less thing to learn about. We wouldn't remove activities right from the start of course, as that would be a breaking change.

Because active activities are represented on the State we should consider adding a new property which would combine both activities and invoked services in a similar manner. @davidkpiano has proposed children as such property:

// OLD (on state.activities, state.children)
activities: {
  beeping: { /* activity id and meta */ }
},
children: { // ... proposed, we can add this in 4.7
  someService: { /* service id and meta, ref */ }
}

// NEW
children: {
  beeping: { /* id and meta */ },
  someService: { /* id and meta, ref */ }
}

Things to consider
Spawned services - their lifetime is not bound to state, so I guess we can't keep them anyhow on State right now.

[qtiki]

I noticed that the xstate visualizer doesn't display activities at all. I was thinking of opening an issue for that but then I found this. So should I future-proof myself and only use invokes/services?

So far I've used services and activites a bit differently. I use services for cases where I need to wait for something to finish and activities for enabling/disabling stuff for a state. For example a loading screen would invoke a loading service while a loading activity would be used to display a loading spinner. This way I can use the loading spinner for any state regardless of how they exit or what they invoke.

So it's more of a naming or structuring thing for me. Of course it's nice that TypeScript prevents you from making an async activity to enforce the activities to use enable/disable toggling functionality. So in short: activities' lifetime is controlled externally by the state while the services are responsible for the final state or onDone transitions. One other thing I've used the activities is to enable or disable UI buttons for a particular state. If I would use these types of activities as a service the state would trigger an unnecessary final state transition instantly which would seem a bit weird.

[davidkpiano]

I will add activities to the visualizer :soon: