@davidkpiano thank you!

⚠️ No Changeset found

Latest commit: 1306626035b90d496c39f70cbe4cb2f63504f4dd

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

<details><summary>This PR includes no changesets</summary>

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

</details>

Click here to learn what changesets are, and how to add one.

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

I've created a readme for @xstate/svelte based on the other integrations. Just a note also to say that there isn't a rollup build step yet so that will need to be added before it can be shipped.

I would start from adjusting what terms are used there - a targetless transition is not a self transitions, at least not according to this glossary: https://statecharts.github.io/glossary/self-transition.html

Thanks for clarifying. Like @Andarist mentioned, the docs could maybe be a bit more specific that targetless transitions will lack entry / exit-set (and thus not trigger entry/exit actions etc).

What I felt was a bit confusing was the following:

First it's mentioning "external transitions will exit and reenter the state node in which the transition is defined".

And then in the next section the following are listed:

• EVENT: { actions: [ ... ], internal: false } - external self-transition
• EVENT: { target: undefined, actions: [ ... ], internal: false } - external self-transition, same as above

Which is stating that the above event types are external and per the first definition exit and re-enter the state node which they are defined in.

Is it correct that targetless external self-transitions exit and re-enter their state nodes, but when they do, they do not have any entry / exit-set?

Maybe it's possible to specify that the last two event types are targetless and that targetless external self-transitions will not trigger entry- or exit actions of the parent state node?

This is working as intended:

The exit set of a transition in configuration C is the set of states that are exited when the transition is taken when the state machine is in C. If the transition does not contain a 'target', its exit set is empty.

The entry set of a transition in configuration C is the set of states that are entered when the transition is taken. If a transition does not contain a 'target', its entry set is empty.

https://www.w3.org/TR/scxml/#SelectingTransitions

That is, regardless of if internal is specified, if there is no target, the state node will not be exited/reentered.

The behavior looks correct - take a look at computeExitSet procedure described here: https://www.w3.org/TR/scxml/#AlgorithmforSCXMLInterpretation

Targetless transitions specifically do not exit any states - we could maybe document this better though. Would you be willing to prepare a docs PR that would make this more clear?

Description <!-- A clear and concise description of what the bug is. --> This is regarding the documentation/functionality w.r.t. external self transitions. I'm not sure if I misinterpreted the docs or if it's a bug.

Expected Result <!-- A clear and concise description of what you expected to happen. --> The documentation at https://xstate.js.org/docs/guides/transitions.html#external-transitions mentions the following:

EVENT: { target: undefined, actions: [ ... ], internal: false } - external self-transition

and

External transitions will exit and reenter the state node in which the transition is defined.

From this I figured something like the following would suffice to re-trigger the entry/exit actions and the invoke on the someState state node when the machine received a SOME_EVENT - event.

{
  ...
  someState: {
    entry: 'someEntryAction',
    exit: 'someExitAction',
    on: {
      SOME_EVENT: {
        internal: false
      }
    },
    invoke: {
      src: someService,
      ...
    }
  }
  ...
}

To get the expected result I had to add an explicit target in the SOME_EVENT transition config.

on: {
  SOME_EVENT: {
    target: 'someState', // <- Here
    internal: false
  }
}

Actual Result <!-- A clear and concise description of what happened instead. --> Neither the entry/exit or invoke occured as I was sending SOME_EVENT to the machine.

Reproduction <!-- Create a reproduction of the issue from one of the following templates: -->

• CodeSandbox template (JavaScript)
• CodeSandbox template (TypeScript)
• ⚛︎ CodeSandbox template (React)
• ⚛︎ CodeSandbox template (React + TypeScript)
• 💚 CodeSandbox template (Vue + Composition API)
• XState Visualizer https://codesandbox.io/s/solitary-dream-oo1cw?file=/src/index.ts

Additional context <!-- Add any other context about the problem here (e.g., XState version) -->

Yeah, this is currently an inconsistency. In v5, the default behavior will be to merge context, so the behavior will become consistent.

Description When the custom initial context is configured with StateMachine.withContext API, the machine's context is completely replaced with the custom context, as explained in the docs. In contrast, when using the React hook useMachine, context passed in the options object is merged with the machine's context. Consider:

machine.withContext({ data: 42 })  // overwrites machine's context
// vs.
// (in a React component)
useMachine(machine, { context: { data: 42 } }) // merges data into machine's initial context

Unless I missed some deeper reasoning, this inconsistency is suboptimal.

Expected Result A consistent behavior when extending state machines with context using both APIs is expected.

Actual Result Two different methods of extending machine with a custom context have different behavior.

Reproduction https://codesandbox.io/s/condescending-kowalevski-z48m2

If you are referring to what events onTransition is being called with - this batching only applies to NULL events (aka always transitions) and raised events. If you send an event FOO to a machine and it specifies a regular send action in a matched transition(s) then this second event won't be "batched" for the purpose of onTransition.

Ah, thanks David!

BTW, I assume XState tries to batch actions, even from different states, until it hits a transition it can not cross. (As opposed to taking each state at a time.) Am I correct?

rxjs, single element in the list, isn't used in the code.

<!-- Reviewable:start -->

This change is <img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/> <!-- Reviewable:end -->

rxjs, single element in the list, isn't used in the code.

This will be coming to v5:

// TENTATIVE API

service.onMicrostep(state => {
  // intermediate state
  console.log(state);
});

I ran into this issue again in my current project where chaining always seemed to not run sequentially, perhaps due to calling external machines / async functions. So not only it is hard to debug, but I don't know how to sequence 'the XState way'; I'll either have to repeat code & use Promise/await, for force users into human await statements. ;)

Could you elaborate?

I would like to separate each action into a single state, so they can be chained by other states. My quiz program is too complex of an example, so I made a simple one:

This is a dice roller that acclimates sums and clear those sums. I added a shortcut to reset-then-roll in one event. You can see with this shortcut, the reset runs, but is not logged.

https://codesandbox.io/s/xstated6roller-rugv5?file=/src/index.js

It was pointing to TS template.

⚠️ No Changeset found

Latest commit: 07ddd800971821ef515b0ada9583db07702f3d8c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

<details><summary>This PR includes no changesets</summary>

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

</details>

Click here to learn what changesets are, and how to add one.

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

It was pointing to TS template.