Better type safety around networked packets

[slice]

(Copied from GH)

The way we model Gateway packets right now isn't wrong:

export interface GatewayMessage {
  op: OPCode
  d?: any
  s?: number
  t?: GatewayMessageType
}

…but, we could take advantage of TS to model them in a more correct fashion. s and t are virtually guaranteed to be non-null if op == OPCode.DISPATCH, so something this could be better:

export type GatewayMessage<Data> =
  { op: OPCode.DISPATCH, data: Data, sequence: number, eventType: string }
| { op: OPCode, data?: Data }

This also:

• renames the fields to be more human-readable
• realizes that the data (d) of a packet should really be unknown, not any. But, since it's the primary encapsulated content of a Gateway packet, so it makes sense to parameterize over it as a generic instead

We can also make more union variants for each OPCode type, and furthermore for each eventType too, probably. This would eliminate a lot of the type annotations from business logic, make it viable to enable strict in tsconfig.json, and give us stronger typing guarantees (meaning, less bugs).

[linear]

PLT-1014 Better type safety around networked packets

(Copied from GH)

The way we model Gateway packets right now isn't wrong:

export interface GatewayMessage {
  op: OPCode
  d?: anya
  s?: number
  t?: GatewayMessageType
}

…but, we could take advantage of TS to model them in a more correct fashion. s and t are virtually guaranteed to be non-null if op == OPCode.DISPATCH, so something this could be better:

export type GatewayMessage<Data> =
  { op: OPCode.DISPATCH, data: Data, sequence: number, eventType: string }
| { op: OPCode, data?: Data }

This also:

• renames the fields to be more human-readable
• realizes that the data (d) of a packet should really be unknown, not any. But, since it's the primary encapsulated content of a Gateway packet, so it makes sense to parameterize over it as a generic instead

We can also make more union variants for each OPCode type, and furthermore for each eventType too, probably. This would eliminate a lot of the type annotations from business logic, make it viable to enable strict in tsconfig.json, and give us stronger typing guarantees (meaning, less bugs).