Enable ReadOnly<NonZeroTuple> for RegisteredEventFactories

[Alan Darmasaputra]

Expected:

SwarmProtocol.make should accept Readonly. See the snippet below

Actual:

As per latest master 0efda8e SwarmProtocol.make doesn't accept Readonly<NonZeroTuple> for the event factories parameters.

Snippet

namespace Events {
  const Opened = MachineEvent.design('opened').withoutPayload()
  const Closed = MachineEvent.design('closed').withoutPayload()
  const Opening = MachineEvent.design('opening').withPayload<{ fractionOpen: number }>()
  const Closing = MachineEvent.design('closing').withPayload<{ fractionOpen: number }>()

  // readonly tuple
  export const all = [Opened, Closed, Opening, Closing] as const;
}

const HangarBay = SwarmProtocol.make('HangarBay', ['hangar-bay'], Events.all)

[Roland Kuhn]

In general, we should audit the current type definitions and use readonly in all places where it is adequate. This will give user code the freedom it needs.

As a starting point (to be refined!): user code should have the freedom to modify the state payload and the event contents in an event handler, and it should be allowed to pass readonly arrays to our API in all places. Event and state factories should be readonly, at least regarding all user-visible properties.

[Alan Darmasaputra]

This will give user code the freedom it needs.

Do you mean, the user should be able to pass readonly as well as non-readonly params? In other word, not to be accidentally "blamed via compiler error" when typing the wrong thing?

OOT, I just realized that this might be an issue

// When Events.all is not readonly
const HangarBay = SwarmProtocol.make('HangarBay', ['hangar-bay'], Events.all)

Events.all.splice(0,1);

[Roland Kuhn]

What I mean is that our API should take readonly data from the user where it doesn’t need to mutate it, and it should probably do defensive copies where needed (as you show above). We should also hand out non-readonly data where it makes sense (i.e. where user wants it or where we hand out a copy in any case) — which is a strict functionality guarantee we give and which we will need to uphold in future versions.