Add initialState option to SpawnOptions and use in Interpreter.spawnMachine()

[nprbst]

I have a (backend) use-case where I need to rehydrate a stand-alone machine and then spawn it as a child of a parent machine awhile later...

The current challenge is that while Interpreter.start() does accept an initialState parameter, Interpreter.spawnMachine() does not.

In essence, I want to be able to do this:

import "./patchedInterpreter";

const spawnOrderMachine = (orderStateData): SpawnedActorRef<OrderMachineEvents> => {
  const previousState = State.create<OrderMachineContext, OrderMachineEvents>(
    orderStateData
  );
  const name = `order_${previousState.context.id}`;
  const orderMachine = createOrderMachine(name, previousState.context);
  const initialState = orderMachine.resolveState(previousState);
  return spawn(orderMachine, { name, initialState });
};

I've prototyped this approach by monkey-patching (!!!) the Interpreter:

patchedInterpreter.ts

import {
  Interpreter,
  EventObject,
  State,
  StateMachine,
  SpawnedActorRef
} from "xstate";
import * as actionTypes from "xstate/lib/actionTypes";
import { toSCXMLEvent } from "xstate/lib/utils";
const DEFAULT_SPAWN_OPTIONS = { sync: false, autoForward: false };

require("monkeypatch-js").patch(
  Interpreter.prototype,
  "spawnMachine",
  () =>
    function spawnMachine<
      TChildContext,
      TChildStateSchema,
      TChildEvent extends EventObject
    >(
      machine: StateMachine<TChildContext, TChildStateSchema, TChildEvent>,
      options: {
        id?: string;
        autoForward?: boolean;
        sync?: boolean;
        initialState?: State<TChildContext, TChildEvent, TChildStateSchema>;
      } = {}
    ): SpawnedActorRef<TChildEvent, State<TChildContext, TChildEvent>> {
      const { initialState } = options;
      const childService = new Interpreter(machine, {
        ...this.options, // inherit options from this interpreter
        parent: this,
        id: options.id || machine.id
      });

      const resolvedOptions = {
        ...DEFAULT_SPAWN_OPTIONS,
        ...options
      };

      if (resolvedOptions.sync) {
        childService.onTransition((state) => {
          this.send(actionTypes.update as any, {
            state,
            id: childService.id
          });
        });
      }

      const actor = childService;

      this.children.set(childService.id, actor);

      if (resolvedOptions.autoForward) {
        this.forwardTo.add(childService.id);
      }

      console.warn("Interpreter.spawnMachine: initialState:", initialState);
      childService
        .onDone((doneEvent) => {
          this.removeChild(childService.id);
          this.send(
            toSCXMLEvent(doneEvent as any, { origin: childService.id })
          );
        })
        .start(initialState);

      return actor;
    }
);

I'm new to XState this week, so I don't know the codebase well. Do those who know it better than I feel that this is a valid approach? Would a PR adding initialState to SpawnOptions be valuable and accepted into the v4 tree?

[Silverwolf90]

This would greatly help out my use case -- and this appears to be pretty straightforward (but I also don't know the codebase well enough to identify any pitfalls).

[Andarist]

One consideration is that this wouldn't translate to SCXML easily. Question - what's your use case:

• rehydrate a single or multiple spawned machines with the stored state but control which ones are rehydrated and which are not
• or maybe rehydrating the whole "tree" (a system) of machines at the same time?

[nprbst]

Thanks @Andarist. Perhaps I'm thinking about this entirely wrong and these child machines shouldn't be spawned, but started in their own interpreters? Does XState allow sending events to machines in un-related interpreters?

Here is my use-case. If you have suggestions for how I could better map this domain to state-charts, I'd be grateful!

• Users are allowed to create one or more Orders from a mobile App, persisted on the backend. These Orders can be acted upon across multiple requests.
• Orders concern themselves with what is being ordered, from who, and by who. They do not care about financial details: Payment, Fees, Taxes, etc.
• Purchases concern themselves with Fees, Taxes, Payments, etc and can take ownership of one or more Orders.
• I want to model and execute the lifecycle of Orders and Purchases using XState, much like the Akka idea of Persistent Actors @davidkpiano linked below.
• The wrinkle is that Orders begin life detached from a Purchase, but are "adopted" by a Purchase when the user chooses to close out their Order and pay. At this point, the idea was to reactivate the Orders as spawned children of the Purchase.
• There is also the case of refunding Orders awhile later. In this case, the Purchase/Orders system needs to be reloaded to it's most-recently persisted state and continue the lifecycle.

Does that all make sense? Any suggestions for the proper way to model these scenarios? I have a shareable Codesandbox where I've been playing around with these ideas. Happy to share that with you...

[nprbst]

Well, I satisfied my curiosity...XState does not have a global address space to send events between Machines (Actors) addressed by ID. That would have been surprising (but awesome)!

[nprbst]

OK. Reading the source, there does appear to be a global registry which is intended to allow addressing running Actors by sessionId. There is even code in the Intepreter.sendTo method which intends to lookup a possible target from the registry:
this.children.get(to as string) || registry.get(to as string)

However, I cannot get this to work for the life of me!

If this sort of cross-machine communication is workable, I can address my use-case in a more natural Actor way without spawning child machines. Can anyone see what I'm doing wrong?

[nprbst]

As a workaround, I can get the actual Order Interpreter from registry myself and directly call send() on that...but in doing so I lose the SCXML event with origin, the ability to respond, and the nice Sequence visualization in inspector. 😞

import { registry } from "xstate/es/registry";
...
const sendPaymentToOrders = (ctx) => {
  return ctx.orderRefs.forEach((ref) => {
    const event = { type: "PURCHASE" };
    console.info("send:", event);
    const target = registry.get(ref);
    if (target) target.send(event);
    // return send({ type: "PURCHASE" }, { to: ref });
  });
};

[davidkpiano]

The reason we're hesitant to give a one-size-fits-all solution to spawned/invoked actor rehydration is because it's a difficult problem to solve that doesn't have a one-size-fits-all solution.

The idea of (re)hydrating a machine to start at any arbitrary state sort of goes against the whole idea of what a state machine is. It also makes it very possible to end up in impossible states.

I say "sort of" because the classic solution to this is event sourcing, and "snapshotting" the state of an actor can be part of the solution, for practical purposes: https://doc.akka.io/docs/akka/current/typed/persistence-snapshot.html#snapshotting

If we snapshot, it needs to be a snapshot of the entire system of actors at a single moment in time, so granular initialState won't work (and is a bit impractical, anyway). I'll play around with this idea soon and maybe come up with a solution.

[nprbst]

Thank you, @davidkpiano. Appreciate the insights! I've described the use case I'm trying to implement in the thread with @Andarist above... Based on that, how would you suggest to model this behavior in XState? Or am I reaching for the wrong tool for the job?

My motivation to see this through: I want to recast some legacy code which is very lengthy, convoluted, difficult to reason about and change into something more declarative, maintainable, and visualizable. XState, with persisted state, seems to be a wonderful approach...especially with the new Inspector viz. (Amazing work!)

With some guidance, I'd be more than happy to do some of the legwork here...

[justrhysism]

Ah, so I guess this PR I just created isn't suitable?

[tomByrer]

I think this is one of the reasons why I avoided Actors & just used individually spawned machines; I can start with unique `context'..