Microsteps #1045
Microsteps #1045
Conversation
🦋 Changeset is good to goLatest commit: 7f3b848 We got this. This PR includes changesets to release 10 packages
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 |
|
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 7f3b848:
|
There was a problem hiding this comment.
This is definitely an improvement 👍
But... if we want to adhere to SCXML semantics I find it hard to keep some of the things, such as resolving some actions (like assign) in the machine rather than in the interpreter.
Take a look at Evaluation of Executable Content - we might notice that actions should actually be grouped in "blocks" where if an exception happens during block's execution the rest of the actions in that block don't happen (only from that very block! other blocks proceed with executions as usual) and an error event gets raised in such a situation. With some things being resolved in the machine it's impossible (or at least hard and not worth it) to match those semantics - because if we have a block such as [send(FOO, { to: 'invalid' }), assign({ answer: 42 })] then this assign action should actually never happen and the context should not get updated.
IMHO we should explore a direction of Machine being pure and very minimal - receiving a current state, an event and returning a description of what should happen during a single transition (in a microstep sense), but what should happen ought to be resolved by the caller as ultimately it is the stateful entity. This would clearly draw a line between the responsibilities of each.
…ll event in state
|
It would be great to add changesets describing public-facing changes & additions, so we don't forget about them in the future. Could you also add tests for your latest changes? |
| } | ||
| ``` | ||
|
|
||
| - Assign actions (via `assign()`) will now be executed "in order", rather than automatically prioritized. They will be evaluated after previously defined actions are evaluated, and actions that read from `context` will have those intermediate values applied, rather than the final resolved value of all `assign()` actions taken, which was the previous behavior. |
There was a problem hiding this comment.
This probably requires removing information about assign being prioritized from the docs.
This PR adds first-class support for representing microsteps through:
machine.microstep(state, event)service.onMicrostep(state => ...)