[v5] Recursive persistence

[davidkpiano]

This PR adds recursive persistence for actors:

const actor = interpret(someMachine).start();

const persistedState = actor.getPersistedState();

// Create actor at persisted state

const restoredActor = interpret(someMachine, {
  state: persistedState
}).start();

You should no longer pass a persisted state into actor.start(...), since it doesn't make sense to provide the persisted state that late (after the actor is already created) and it makes the initial state inconsistent:

-interpret(machine).start(someState);
+interpret(machine, { state: someState }).start();

[changeset-bot]

🦋 Changeset detected

Latest commit: 7489eb6

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 7489eb6:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[ghost]

👇 Click on the image for a new way to code review

Legend

[Andarist]

when the subscription can be missing when receiving stopSignalType? This sounds like an impossible state

[Andarist]

Ah, stopSignalType is coming from an external .stop(), hmmm. It might be needed to have some guard in place here for this case - but I wonder about the exact scenario related to this because it seems that we don't have a test for it.

[davidkpiano]

If you restore the observable actor and it's already completed, subscription will be undefined.

[Andarist]

Yes, but this line of code is specifically called at some point - and we should have a test case that would hit this line of the code when the subscription is absent (and we dont have such rn)

[davidkpiano]

I can but isn't ?. safer? I'm not sure what should be tested here since the code won't fail regardless of if it's defined or not. We would be testing the change from ! to ? which is sorta meaningless.

Do we need to test all the places where we have ?.?

[Andarist]

I can but isn't ?. safer?

It is. But it's also potentially a little bit of redundant code, runtime overhead etc. I find defensive programming often obscures the meaning of the code and covers up potential bugs.

For example, from my PoV the important question here is - can the stopSignalType even be received when state.subscription === undefined? If the answer is "no" but it happens anyway then this ?. will "swallow" the logical/integration bug and we won't even learn about it if it ever happens. If the answer is "yes" then we can write a test case that would exercise this scenario and we can verify there that nothing throws (and then we will be sure that ?. is actually needed!)

[davidkpiano]

I reverted this

[Andarist]

what about a canceled actor? a canceled actor is pretty much "completed" (even if not successfully). OTOH, a canceled actor might not get persisted at all, right? Since it should be cleaned up from state.children.

This also brings an important issue here - spawned actors (including stopped ones) might be part of the context. We are not doing anything about this and likely we should. They should be rehydrated in the same way as the invoked ones - the fact that they live in context complicates the matter though :s

[davidkpiano]

For spawned actors, follow-up PR?

[Andarist]

👍