Drop support for handling promises returned by fromCallback

[Andarist]

My main rationale for this is that it's an easy mistake to do this:

fromCallback(async (sendBack) {
  const api = await getSomeApi()
  api.onFoo = (val) => sendBack({ type: 'EV', val })
})

The problem with this code is that this promise implicitly completes very quickly and thus the parent stops accepting events sent out from this callback. Here the async was used as a convenient mechanism to use await, the intention wasn't really to complete this callback actor with undefined. Note that this is not a made-up example - this has been reported a while back on Discord by Kent and the resulting situation was quite hard to debug for a user because XState was logging cryptic errors in this case.

This can easily be refactored to:

fromCallback(() => {
  (async (sendBack) {
    const api = await getSomeApi()
    api.onFoo = (val) => sendBack({ type: 'EV', val })
  })()
})

Note that supporting promises (what is being removed from here) doesn't also play that well with current types as the return value of fromCallback is Behavior<TEvent, undefined> whereas that undefined is not a strong guarantee with a returned promise.

[changeset-bot]

🦋 Changeset detected

Latest commit: d6311a2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
xstate	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit d6311a2:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[ghost]

CodeSee Review Map:

Review in an interactive map

View more CodeSee Maps

Legend

[Andarist]

Alternatively we could allow promises but ignore the completion value. In such a case though - what to do about errors? We probably should handle them but then out handling wouldnt be symmetric (and thus somewhat weird)

[davidkpiano]

I'm in favor of this; can you re-merge the v5/improved-spawn-1 PR as there are new changes?

[Andarist]

@davidkpiano ye, gonna handle the merge tomorrow

@mattpocock would love your input on this one too

[Andarist]

This was already approved before but it got stale and I just rebased it. @davidkpiano could you take a second look at this?