Defining shared system actions

[with-heart]

I'm building a system that defines a lifecycle-manager machine which sends system lifecycle events (update.pre, update, update.post) to subscribed listeners in a consistent loop:

I'd like to allow actors in the system to subscribe to whichever events they need access to and be notified of the events at the appropriate point in the lifecycle. For example, I'd like the renderer to subscribe to update.pre so it can clear the canvas before rendering anything and update.post so it can draw each drawable to the canvas:

As you can see, renderer has the entry actions subscribeUpdatePre and subscribeUpdatePost. Using sendTo, it's not that difficult to implement subscription in my machine's setup config:

export const rendererMachine = setup({
  types: {
    events: {} as UpdatePreEvent | UpdatePostEvent,
  },
  actions: {
    subscribePreUpdate: sendTo(
      ({ system }) => system.get('lifecycle-manager'),
      ({ self }) =>
        ({
          type: 'register.update.pre',
          ref: self,
        }) satisfies RegisterUpdatePreEvent,
    ),
    subscribePostUpdate: sendTo(
      ({ system }) => system.get('lifecycle-manager'),
      ({ self }) =>
        ({
          type: 'register.update.post',
          ref: self,
        }) satisfies RegisterUpdatePostEvent,
    ),
  },
}).createMachine({
  id: 'renderer',
  entry: ['subscribePreUpdate', 'subscribePostUpdate'],
})

However, let's imagine this system is shared by many different actors, each of which would like to subscribe to some combination of the update, update.pre, and update.post events. This now becomes a significant amount of boilerplate as each actor's setup config needs to implement the same exact subscribe actions.

I'd like to be able to define generic implementations of those actions so that any actor in the system can re-use them. This would allow my system to avoid the boilerplate of each subscriber needing to implement the same subscription logic over and over again.

We can already achieve this thanks to sendTo + callbacks for both the to and eventOrExpr params:

export const subscribePreUpdate = sendTo(
  ({ system }) => system.get('lifecycle-manager'),
  ({ self }) =>
    ({
      type: 'register.update.pre',
      ref: self,
    }) satisfies RegisterUpdatePreEvent,
)

export const subscribeUpdate = sendTo(
  ({ system }) => system.get('lifecycle-manager'),
  ({ self }) =>
    ({ type: 'register.update', ref: self }) satisfies RegisterUpdateEvent,
)

export const subscribePostUpdate = sendTo(
  ({ system }) => system.get('lifecycle-manager'),
  ({ self }) =>
    ({
      type: 'register.update.post',
      ref: self,
    }) satisfies RegisterUpdatePostEvent,
)

But unfortunately, I haven't been able to find a way to make the generic types match up in a way that doesn't cause errors at the use site. When I drop these functions straight into setup for rendererMachine (setup({ actions: { subscribePreUpdate, subscribePostUpdate } })), I receive type errors like this:

Type 'ActionFunction<MachineContext, EventObject, EventObject, NonReducibleUnknown, never, never, never, never, never>' is not assignable to type 'ActionFunction<MachineContext, UpdatePreEvent | UpdatePostEvent, UpdatePreEvent | UpdatePostEvent, ... 5 more ..., EventObject>'.
  Type 'EventObject' is not assignable to type 'UpdatePreEvent | UpdatePostEvent'.
    Type 'EventObject' is not assignable to type 'UpdatePostEvent'.
      Types of property 'type' are incompatible.
        Type 'string' is not assignable to type '"update.post"'.ts(2322)

It's reporting errors because the generic EventObject used by the sendTo function isn't assignable to the machine-specific event types used by the consuming actor.

Here's a StackBlitz link showing these type errors: https://stackblitz.com/edit/github-vrnmq81x?file=src%2Frenderer.ts&view=editor

Ideally I'd like to get even more specific with these actions. For example, only a machine that includes UpdateEvent in the setup.types.events union should be able to use subscribeUpdate as an action. But for now, I think just figuring out how to use these for any actor would be a good start.

Any ideas?

[with-heart]

I ended up defining the functions like this:

type SubscribeFunction = ActionFunction<
  MachineContext,
  any,
  any,
  any,
  any,
  any,
  any,
  any,
  never
>

export const subscribePreUpdate: SubscribeFunction = sendTo(
  // @ts-expect-error implicit any for system
  ({ system }) => system.get('lifecycle-manager'),
  ({ self }) =>
    ({
      type: 'register.update.pre',
      ref: self,
    }) satisfies RegisterUpdatePreEvent,
)

export const subscribeUpdate: SubscribeFunction = sendTo(
  // @ts-expect-error implicit any for system
  ({ system }) => system.get('lifecycle-manager'),
  ({ self }) =>
    ({ type: 'register.update', ref: self }) satisfies RegisterUpdateEvent,
)

export const subscribePostUpdate: SubscribeFunction = sendTo(
  // @ts-expect-error implicit any for system
  ({ system }) => system.get('lifecycle-manager'),
  ({ self }) =>
    ({
      type: 'register.update.post',
      ref: self,
    }) satisfies RegisterUpdatePostEvent,
)

This allows the functions to be used in setup.actions for any machine.

The @ts-expect-error lines are required because ts thinks binding element system is implicitly defined as any for some reason.

I was also able to define them using this style:

export const subscribePreUpdate = sendTo<
  MachineContext,
  any,
  any,
  AnyActorRef,
  any
>(
  ({ system }) => system.get('lifecycle-manager'),
  // @ts-expect-error implicit any for self
  ({ self }) =>
    ({
      type: 'register.update.pre',
      ref: self,
    }) satisfies RegisterUpdatePreEvent,
)

but that just moves the @ts-expect-error to self.

Not sure there are really any good options here which is frustrating because it means we can't provide type safety for things shared across a system. Better than nothing though!

[with-heart]

Actually the @ts-expect-error directives are weird because the implicit any error is reported inconsistently. Sometimes system has the error for only one function, sometimes for all three, sometimes for none of them. Not really sure how to get around that.

I was able to get around it by using providing generic args to sendTo rather than using the SubscribeFunction. self always reports an implicit any error.