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[bot]]

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 = { 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).