4.15.1 spawn return type causing issues, useActor() vs useService()?

[joshuaaron]

Description
The type returned from the spawn() method now returns a SpawnedActorRef, instead of Interpreter.
I'm unsure if I should be using useService() vs useActor() to use these spawned actors in the 'child', as I would like to access the full machine for the child to get the full current state and utilize .matches etc.

Currently, if I use useActor() I only get the [currentEvent, send] though if I try and use useService(), an error arises saying I've tried to use an actor in the service, please use useActor() instead.

Am I left to use useActor here, and possibly architect the app differently? I was considering downgrading my version to receive the Interpreter return type back.

Apologies if this hasn't made as much sense, or if I'm going about this the wrong way, this is my first experience with xstate so I may be going about this incorrectly. Trying to convince my team to move over some complex UI to xstate and we're just dipping our feet.

Codesandbox here

[Andarist]

You should use useActor but type your ref differently - you can do this:

export type AccordionPanelMachineInterpreter = ActorRefFrom<
  Interpreter<AccordionPanelContext, any, AccordionPanelEvents>["machine"]
>;

Take a look at the adjusted codesandbox: https://codesandbox.io/s/stoic-glitter-ojyy4

[joshuaaron]

@Andarist wonderful thank you.

For the example above, do you think that the structure of spawning refs and communicating events through send is the way to go? or should these be two separate machines, where the component subscribing to the panel machine (child) could receive an open prop and then send local events via an useEffect hook to detect a change?

Struggling with a mental model of what to do purely in xstate vs how much to let react handle things

[Andarist]

It looks OK - my general advice is that you should focus more on what you feel comfortable with and maybe expand to other alternatives when you start feeling more comfortable with a particular paradigm. Start small, solve problems 😉

There is nothing wrong with how you have handled this here.

[joshuaaron]

Great will do, thanks for the feedback!