Types for WebSocketPair

[ssttevee]

Any plans for adding types related to websockets as seen in https://github.com/cloudflare/workers-chat-demo?

There doesn't seem to be any documentation on the the cloudflare docs so even writing it myself would be difficult. 😢

[sepbot]

export {}

declare global {
  interface WebSocket {
    accept(): void;
  }

  class WebSocketPair {
    0: WebSocket;
    1: WebSocket;
  }

  interface ResponseInit {
    webSocket?: WebSocket;
  }
}

[stof]

the doc is now available at https://developers.cloudflare.com/workers/runtime-apis/websockets

[hronro]

Any updates?
Why those types are not included in this library?

[helloimalastair]

Any updates?
Why those types are not included in this library?

Try adding a pull request, it might make it faster for them to make changes if all they have to do is review your code.

[OwenDelahoy]

export { }

declare global {
  interface CloudflareWebsocket {
    accept(): unknown;
    addEventListener(event: 'close', callbackFunction: (code?: number, reason?: string) => unknown): unknown;
    addEventListener(event: 'error', callbackFunction: (e: unknown) => unknown): unknown;
    addEventListener(event: 'message', callbackFunction: (event: { data: any }) => unknown): unknown;
    
    /**
     * @param code https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent
     * @param reason
     */
    close(code?: number, reason?: string): unknown;
    send(message: string|Uint8Array): unknown;
  }

  class WebSocketPair {
    0: CloudflareWebsocket; // Client
    1: CloudflareWebsocket; // Server
  }

  interface ResponseInit {
    webSocket?: CloudflareWebsocket;
  }
}

[aboodman]

Warning to anyone else using these types:

Using sepbot's suggestion (#84 (comment)) has the effect of adding accept() to any pre-existing WebSocket definition. In most cases, this will be the standard DOM WebSocket in your code.

This would be fine if Cloudflare Workers actually implemented the complete WebSocket spec, but it doesn't. For example, the readyState property from the spec is not currently supported.

I suggest using instead something like OwenDelahoy's suggestion (#84 (comment)) will narrowly defines only the features actually supported by CF workers.