Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support generic sent event types (sendBack events) to callback-based actors #5143

Conversation

steveadams
Copy link
Contributor

@steveadams steveadams commented Dec 12, 2024

As mentioned in Discord, I don't think this is supported presently. With no typing, it's possible to place arbitrary events into the sendBack method. With this change (currently intended to be a suggestion; some things are broken), the types do work as I want them to in my use-cases so this seems to be on the right track.

One existing solution to this problem is to type the events like this:

export type SegmenterEvent =
  | {
      type: 'SEGMENT_CREATED';
      eventID: string;
      eventData: EventData;
    }
  | {
      type: 'SEGMENTER_FINISHED';
      segmenterID: string;
    }
  | {
      type: 'SEGMENTER_FAILED';
      segmenterID: string;
      error: unknown;
    };

export const segmenter = fromCallback(
  ({ input, sendBack }: { input: SegmenterInput; sendBack: (e: SegmenterEvent) => void }) => {
    const segmentEventData = async () => {

With this proposed change, the goal is to be able to type them like this:

export const segmenter = fromCallback<AnyEventObject, SegmenterInput, AnyEventObject, SegmenterEvent>(
  ({ input, sendBack }) => {
    const segmentEventData = async () => {

Both versions are quite verbose, but for callbacks with received, emitted, and sent events, it could be quite a bit cleaner.

Remaining:

  • Determine if anyone else thinks this is a good idea
  • Include changeset
  • Figure out why typecheck is failing. It appears to be failing on main as well, but not sure if this is a caching/local issue of some sort. I'll look closer
  • Review if the changes are made correctly, or only match my use case coincidentally while it might break others

Copy link

changeset-bot bot commented Dec 12, 2024

⚠️ No Changeset found

Latest commit: 4bf2363

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@Andarist
Copy link
Member

It requires a little bit of manual plumbing but the preferred approach to get what you want is this (TS playground):

import { setup, fromCallback, ActorRef, Snapshot } from "xstate"; // types: 5.19.0

type ParentEvent = { type: "TO_PARENT" } | { type: "ANOTHER_TO_PARENT" };

setup({
  types: {} as {
    events: ParentEvent;
  },
  actors: {
    foo: fromCallback(
      ({
        input: { parent },
      }: {
        input: { parent: ActorRef<Snapshot<unknown>, ParentEvent> };
      }) => {
        parent.send({
          type: "TO_PARENT",
        });
        parent.send({
          // @ts-expect-error
          type: "unknown",
        });
        return () => {};
      },
    ),
  },
}).createMachine({
  invoke: {
    src: "foo",
    input: ({ self }) => ({ parent: self }),
  },
});

Introducing a new generic introduces coupling between actor definitions in a way that is meaningless for non-callback actors. Other actor types can't send events to their parents without using a pattern like the above after all.

@steveadams
Copy link
Contributor Author

Ah, I see why this wasn't done already then. Thank you for explaining it to me. I'll stick with the manual plumbing!

@steveadams steveadams closed this Dec 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants