Fixed an issue with interpreters started using a persisted state not being "resolved" in full #3140
Conversation
…being "resolved" in full
🦋 Changeset detectedLatest commit: c3e2b75 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
CodeSee Review Map:Review in an interactive map View more CodeSee Maps Legend |
|
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 c3e2b75:
|
| // this is usually called by `machine.getInitialState` but if we rehydrate from a state we might bypass this call | ||
| // we also don't want to call this method here as it resolves the full initial state which might involve calling assign actions | ||
| // and that could potentially lead to some unwanted side-effects (even such as creating some rogue actors) | ||
| (this.machine as any)._init(); |
There was a problem hiding this comment.
This should really only be called here:
xstate/packages/core/src/StateNode.ts
Lines 464 to 468 in c3e2b75
but we are still blocked by supporting "getters" for targets so we can't call this in a constructor as the machine doesn't get yet returned to the caller at this point in time and thus a thing like this fails on reading from undefined:
xstate/packages/core/test/id.test.ts
Lines 52 to 54 in c3e2b75
fixes #3111