Best Way To Access invoked Actor from Parent using @xstate/react

[TheNoodleMoose]

Hi there!

First off want to say I love this library so much, thank you guys for all your great work! I'm newer to XState and state machines in general so still continuing to learn more and more everyday 😄

I'm in the process of upgrading/rewriting a couple of machines from V4 -> V5. These machines are used for a multistep wizard, where we have different 'steps', each step having different data. We also have the need to handle the fetching of previous save data for that step, saving the step, errors when saving the step, etc (which is handled in a separate machine called updatedCaseMachine).

The parent machine (called caseMachine) will invoke said separate machine (updateCaseMachine) on each new state(or step). Here's an example of this for one of the states(steps):

physician: {
      invoke: {
        src: "updateCaseMachine",
        id: "PhysicianStep",
        input: ({ context }) => ({
          ...context,
          step: "physician",
        }),
        onDone: [
          {
            target: "member",
            actions: [
              assign({
                physicianStepInfo: ({ event }) =>
                  event.output.physicianStepInfo,
                caseId: ({ event }) => event.output.caseId,
                error: false,
                errorMsg: "",
              }),
            ],
          },
        ],
        onError: [
          {
            target: "physician",
            actions: [
              assign({
                error: true,
                errorMsg: "An error occured while saving physician step",
              }),
            ],
          },
        ],
      },
    },

I'm now using XState V5 in tandem with @xstate/react, and I'm using the machine in my main wizard component like so:

  const [state, send, actorRef] = useMachine(caseMachine, {
    input: {
      ...someInputStuffHere
    },
  });

Previously before in V4 and the older @xstate/react, I would pass the actorRef to one of my step components via props and then proceed to get the spawned child actor in the step component like so:

 const machine = actorRef.children.get("PhysicianStep");
 const [current, send] = useActor(machine as Interpreter<any, any, any>);

This would give me access to updateCaseMachine's state (via current), which I could use to know the state of that invoked instance of updateCaseMachine as well as send events in order to save the step, etc. I wasn't the biggest fan of this implementation, and my biggest gripe was I couldn't get the typing for actorRef figured out so eventually just typed it as any losing all typescript inference.

The individual step components don't really care about the parent machine's state but mainly the invoked instance of updateCaseMachine for that particular step. So my main question is, with V5 and the newer version of @xstate/react is there a better way to get the state for that spawned machine on a particular step? Or am I thinking about this all wrong? Sometimes it feel like that's the case haha

A little lost and would appreciate any help on this! Thank you!

[with-heart]

The individual step components don't really care about the parent machine's state but mainly the invoked instance of updateCaseMachine for that particular step. So my main question is, with V5 and the newer version of @xstate/react is there a better way to get the state for that spawned machine on a particular step? Or am I thinking about this all wrong? Sometimes it feel like that's the case haha

Could you give an example of another state that uses updateCaseMachine besides physician? I think the differences between them might determine how best to proceed here.

[TheNoodleMoose]

Sure thing! So here's the member step state:

    member: {
      invoke: {
        src: "updateCaseMachine",
        id: "MemberStep",
        input: ({ context }) => ({
          ...context,
          step: "member",
        }),
        onDone: [
          {
            target: "procedure",
            actions: [
              assign({
                memberStepInfo: ({ event }) => event.output.memberStepInfo,
                treatmentRequestId: ({ event }) =>
                  event.output.treatmentRequestId,
                caseId: ({ event }) => event.output.caseId,
                error: false,
                errorMsg: "",
              }),
            ],
          },
        ],
        onError: [
          {
            target: "member",
            actions: [
              assign({
                error: true,
                errorMsg: "An error has occured while saving the member step",
              }),
            ],
          },
        ],
      },
      on: {
        BACK: {
          target: "physician",
        },
      },
    },

and it pretty much is exactly the same for all the other step states, only thing being different per state invoke is the step value for the input when invoking updateCaseMachine, and then the on onDone, onError, BACK event target.

Main line of thinking is, the caseMachine simply keeps track of which step we are in, is the house for all the data once we have it, and handles the flow of the case wizard. While the updateCaseMachine is what's in charge of the actual business logic for fetching, saving, etc on a step. It will then pass the data back to the caseMachine and we update it's context. Feel like the separation of concerns is a good one. updateCaseMachine is essentially reusable, and based on what input value is for step, it knows what to do for that particular step.

Here's the states and output for updateCaseMachine just to show what we're doing their as well:

  states: {
    fetch: {
      on: {
        NEXT: {
          target: "edit",
          actions: "assignStepContext",
        },
        ERROR: {
          target: "edit",
          actions: "assignErrorContext",
        },
      },
      invoke: {
        src: "handleFetchStepData",
        input: ({ context, event }) => ({
          caseContext: context,
          step: event.type === "NEXT" ? event.step : "",
        }),
      },
    },
    edit: {
      on: {
        NEXT: {
          target: "pending",
          actions: "assignStepContext",
        },
      },
    },
    pending: {
      on: {
        NEXT: {
          target: "done",
          actions: "assignStepContext",
        },
        ERROR: {
          target: "edit",
          actions: "assignErrorContext",
        },
      },
      invoke: {
        src: "handleSaveStepData",
        input: ({ context, event }) => ({
          caseContext: context,
          step: event.type === "NEXT" ? event.step : "",
          stepData: event.type === "NEXT" ? event.stepData : null,
          hasFormUpdate: event.type === "NEXT" ? event.hasFormUpdate : false,
        }),
      },
    },
    done: {
      type: "final",
    },
  },
  output: ({
    context: {
      physicianStepInfo,
      memberStepInfo,
      procedureStepInfo,
      diagnosisStepInfo,
      facilityStepInfo,
      recommendationStepInfo,
      caseId,
      treatmentRequestId,
      thirdPartySsoToken,
      thirdPartyUserId,
    },
  }) => ({
    physicianStepInfo,
    memberStepInfo,
    procedureStepInfo,
    diagnosisStepInfo,
    facilityStepInfo,
    recommendationStepInfo,
    caseId,
    treatmentRequestId,
    thirdPartySsoToken,
    thirdPartyUserId,
  }),

[ersinakinci]

@TheNoodleMoose did you ever figure out a better way? I'm facing the exact same issue with my parent-child wizard machine system.

@with-heart any ideas?

[TheNoodleMoose]

@TheNoodleMoose did you ever figure out a better way? I'm facing the exact same issue with my parent-child wizard machine system.

@with-heart any ideas?

I did figure out a solution but not the way I had originally intended. After writing everything out I did in fact realize that they were two separate machines and did not necessarily need to be 'aware' internally of each others state. So the two machines are completely separate now, and I individually invoke updateCaseMachine for each step in that steps component. I then pass down a function via props that will move caseMachine to it's next state (or the essentially the next step). To listen for when to correctly do this I have the following useEffect:

  useEffect(() => {
    // Subscribe to updateCaseMachine
    const subscription = actorRef.subscribe((snapshot) => {
      // listen for done status
      if (snapshot.status === "done") {
        // call our handleSubmitStep to transition to next state in caseMachine and update caseMachine context with output from updateCaseMachine
        handleSubmitStep(snapshot.output);
      }
    });

    return subscription.unsubscribe;
  }, [actorRef]);

This separation has actually helped to clean things up a lot and simplify the machines. Just took me a bit to think of the different approach compared to how I was doing it before in v4.