[v5] System (receptionist)

[davidkpiano]

This PR creates an implicit system and provides it in the machine implementations:

const machine = createMachine({
  id: 'parent',
  initial: 'a',
  states: {
    a: {
      invoke: [
        {
          src: fromCallback((_, receive) => {
            receive((event) => {
              expect(event.type).toBe('HELLO');
            });
          }),
          key: 'receiver'
        },
        {
          src: createMachine({
            id: 'childmachine',
            entry: (_ctx, _ev, { system }) => {
              const receiver = system.get('receiver');

              if (receiver) {
                receiver.send({ type: 'HELLO' });
              }
            }
          })
        }
      ]
    }
  }
});

[changeset-bot]

🦋 Changeset detected

Latest commit: 84af883

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 84af883:

Sandbox	Source
XState Example Template	Configuration
XState React Template	Configuration

[ghost]

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

Legend

[tivac]

(Sorry if this is an obvious question, can't look through the changes atm)

Is the system accessible from the interpreter for outside use as well?

[with-heart]

Love this so much. It's a testament to the system yall have built that such a powerful feature requires so little to code implement. Super excited for this!

[davidkpiano]

(Sorry if this is an obvious question, can't look through the changes atm)

Is the system accessible from the interpreter for outside use as well?

It is "not" (at least not naturally)... but of course, once you have access to the { system } grabbed from an action, we can't stop you from passing that reference around 🤷

[tivac]

Is there a previous discussion on why that isn't allowed?

With how we use child machines being able to send events to specific ones instead of blasting everybody or manually plumbing through the parent seems really valuable.

[davidkpiano]

Is there a previous discussion on why that isn't allowed?

With how we use child machines being able to send events to specific ones instead of blasting everybody or manually plumbing through the parent seems really valuable.

Maybe I'm misreading the question, but from any descendant machine within the same system, you have access to the system, so yes, you can send events to specific actors ('blah' in this case) instead of "blasting".

[tivac]

@davidkpiano I'm talking about something like this:

import { createMachine, interpret } from 'xstate';

const rootMachine = createMachine({
  /* ... */
});

const service = interpret(rootMachine);

service.start();

const receiver = service.system.get("receiver");

if(receiver) {
  receiver.send({ type: 'HELLO' });
}

Since we're using xstate-component-tree to manage components that are being rendered, and sometimes components want to fire an event back into the statechart that spawned them. Currently xstate-component-tree offers a .broadcast(<event>) API that literally sends the event into every running statechart but that's a little coarse and dangerous for my tastes.

I guess since xstate-component-tree is actively tracking the running children at any given time it could provide a service-style API, maybe, but I was hoping that this would let me rip all that logic out of my code and use something built-in and more standard.

[davidkpiano]

@tivac Ah okay, I understand; you want to access the service completely outside the machine.

I agree that this should be made possible by the API you've described:

const receiver = service.system.get('receiver');

I'll add tests for this.

[Andarist]

this one could be called unconditionally, otoh - it kinda doesn't matter cause you are using WeakMap, in a way... there is no point in this .delete call at all, the engine itself should just clean this up - that's the whole point of the Weak part in the WeakMap

[Andarist]

I wonder if this shouldn't accept the same generic as ActorSystem itself accepts. Not a big deal though and I don't have a strong opinion about this right now.

[davidkpiano]

Can change it later; if for whatever reason a dev needs to manually construct this, this type can be typeof someSystem rather than ActorSystemInfoFrom<typeof someSystem>

[Andarist]

#yoda

[Andarist]

Don't worry about this right now but I find defining a type like this here extremely annoying to work with. It's not exactly an "abstract" type that comes with no direct implementation. It has a single implementation in the system.ts and whenever I cmd+click on ActorSystem I'm being brought to here by the IDE which isn't that helpful (going to the implementation in the system.ts would be way more useful in this instance)

[davidkpiano]

Want a class instead?

[Andarist]

the current runtime code is fine - but the type definition could be derived from the implementation or just declared next to the implementation then jumping to it would at least bring us to the correct file

[davidkpiano]

the current runtime code is fine - but the type definition could be derived from the implementation or just declared next to the implementation then jumping to it would at least bring us to the correct file

I'm open to having this be refactored, if you want to (not immediately sure how to do this)